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ABSTRACT 


The  NFS  Autonomous  Underwater  Vehicle  Simulator  is  a  joint  project  between  the 
Naval  Postgraduate  School’s  Mechanical  Engineering  and  Computer  Science 
Departments.  In  order  to  test  mission  planning  and  execution  software,  an  accurate  vehicle 
dynamic  model  is  required.  Using  dynamics  based  upon  the  Navy’s  Swimmer  Delivery 
Vehicle  (SDV),  there  is  a  need  to  continually  update  the  hydrodynamic  coefficients  based 
upon  actual  vehicle  in-water  testing.  The  NPS  AUV  Dynamic  Sirnulator  contains  a  full  set 
of  submarine  equations  of  motion  and  hydrodynamic  coefficients.  The  coefficients  are 
mtxiifiable  on-line,  and  a  replay  capability  exists  for  further  performance  review. 

Using  Monterey  Bay  as  an  underwater  testing  environment,  there  is  the  need  to  be  able 
to  display  expansive  tenain  data  while  maintaining  the  real  time  siinulation.  ’  ."he  Variable 
Terrain  Resolution  Algorithm  incorporated  into  the  NPS  AUV  Dynamic  Simulator  enables 
the  entire  Monterey  Bay  data  base  to  be  displayed  in  real  time.  Resolution  adjustments  are 
automatically  based  upon  the  vehicle’s  depth  level  and  system  perfonrance. 
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1.  INTRODUCTION 


A.  BACKGROUND 

There  is  a  growing  effort  within  tlie  Department  of  Defense  to  develop  autonomous 
underwater  vehicles.  Without  the  need  to  incorporate  life  support  systems,  there  is  promise 
that  an  AU'.'  can  do  a  variety  of  missions  at  less  expense,  and  without  danger  to  human  life. 
During  software  and  hardware  development,  there  is  a  risk  of  loss  of  an  autonomous 
underwater  vehicle  if  actually  deployed,  therefore,  software  must  be  thoroughly  tested, 
preferably  in  its  expected  environment.  With  the  advent  of  high  speed,  low  cost  graphics 
workstations,  it  is  now  possible  simulate  submarine  dynamics  in  real  dme.  Controller  and 
mission  planning  software  can  be  tested  and  real  time  feedback  obtained.  Using  imderwater 
grid  terrain  data,  such  as  that  available  from  the  Defense  Mapping  Agency,  missions  can 
potentially  be  simulated  anywhere  in  the  world,  at  any  depth.  Various  mission  factors  such 
as  changing  ciurcnts,  unplanned  obstacles,  and  vehicle  centred  surface  failure  can  be 
observed  prior  to  executing  various  missions.  By  incorporating  the  AUV  into  simulators 
such  as  the  NPSNET  (Zyda,  Pratt  1990),  vehicle  missions  can  be  executed  in  conjunction 
with  a  coordinated  operations  scenario.  In  order  to  run  these  missiems  in  real  time, 
algorithms  need  to  be  developed  to  make  optimum  usage  of  the  workstation's  graq;hics 
.  c^abilities. 

B.  FOCUS -NPS  AUV  DYNAMIC  SIMULATOR 

This  thesis  concentrates  on  two  main  aspects.  The  first  is  to  develop  tlw  ability  to 
generate  accurate  hydrodynamic  coefficients  and  submarine  equations  of  motions.  The 
second  is  to  portray  the  vehicle  in  its  anticipated  environment  in  retd  time. 


By  accurately  predicting  vehicle  performance,  system  software  can  be  developed  and 
tested  prior  to  incorporation  into  the  actual  vehicle.  The  NTS’  AUV  Dynamic  Simulator 
enables  the  user  to  record  vehicle  performance  with  any  set  of  hydrocoefficients.  System 
response  on  the  simulator  can  be  compared  to  in-water  vehicle  testing,  coefficients  adjusted 
on-line,  and  simulator  performance  obseived  until  it  emulates  the  actual  vehicle.  Du-ough 
this  bootstrapping  effect,  an  accurate  graphics  model  can  be  developed  without  the  need  to 
perform  expensive  test-tank  operations. 

The  Monterey  Bay  database  was  used  to  develop  the  terrain  rendering  algorithm 
utilized  in  the  NFS  AUV  Simulator.  The  proximity  of  the  bay  to  the  Naval  Postgraduate 
School  (NFS)  combined  with  the  interesting  subterrain  features  of  the  Monterey  Bay 
Canyon,  make  the  bay  a  logical  choice,  for  future  test  runs  of  the  actual  vehicle.  Mission 
planiung  systems  can  be  used  to  generate  proposed  paths  through  the  canyon.  Bay  currents 
can  be  incorporated  into  the  model.  While  most  of  the  actual  vehicle  testing  is  done  in  the 
constraints  of  the  NFS  swimming  pool,  full  dynamic  and  artificial  intelligence  software 
testing  require  a  more  expansive  area.  The  Variable  Terrain  Resolution  Algorithm 
developed  herein  can  be  ported  to  otlier  simulators  using  DMA  Digital  Terrain  Data  such 
as  NFS  Command  and  Control  Workstation  of  -he  Future  (Weeks,  Phillips  1989). 

C.  THESIS  ORG  ANIZATION 

Chapter  II  provides  a  background  on  other  vehicle  simulators  developed  at  NFS.  The 
development  and  refinement  of  teirain  rendering  algorithms  is  traced  through  the  various 
simulators  at  NTS.  The  use  of  dynamics  to  graphically  iiKxiel  the  NFS  AUV  is  traced  from 
die  simulator’s  origin  to  the  cunent  model  NFS  AUV  III. 

Chapter  HI  describes  the  techniques  utilized  in  the  NFS  AUV  Simulator  to  portray  the 
environment  in  real  time.  These  techniques  include  high  speed  terrain  drawing  routines, 
variable  terrain  resolution  display,  and  field  of  view  culling. 


Chapter  IV  provides  details  and  performance  measurements  of  the  Variable  Terrain 
Resolution  Algorithm  (VTRA )  used  to  display  Monterey  Bay.  VTRA  is  a  recursive,  binary 
reduction  technique  for  displaying  grid  terrain  about  an  observer  to  the  horizon. 

Chapter  V  describes  the  ADV  data  structure.  By  taking  an  object  oriented  approach, 
the  submarine  can  inherit  rigid  body  properties  while  maintain  those  unique  to  a  submarine 
environment. 

Chapter  VI  discussed  the  dynamics  model  used  for  AUV  HI.  The  AlA'^  equations  of 
motion  and  hydrodynamic  coefficients  are  described.  The  procedure  for  converting 
thrusters  ipm  and  fin  deflections  to  veliicle  motion  is  discus.sed. 

Chapter  Vn  details  how  to  operate  the  AUV  Simulator.  The  User  Interface  is  described 
along  witii  the  system  capabilities. 

Chapter  Vtll  provides  the  limitations  and  future  direction  of  the  project. 


11.  SURVEY  OF  PREVIOUS  WORK 


A.  NPS  SIMULATOR  REVIEW 

1.  Fiber  Optically  Guided  Missile  (FOGM)  Simulator 

The  FOGM  simulator,  implemented  on  the  SGI  IRIS  3120  woricstation,  featured 
a  10  kilometer  by  10  kilometer  grid  terrain  data  base  of  Fort  Hunter  Liggett,  California 
(Smith  1987).  The  data  was  presented  as  3-sided  polygons  using  a  Painter’s  algorithm 
where  each  polygon  is  scan  converted  drawing  the  closest  polygons  last  while  “painting 
over”  further  polygons.  All  terrain  was  drawn  at  a  constant  resoludon,  including  terrain 
hidden  from  the  observer.  FOGM  maintained  a  frame  rate  of  three  to  four  frames  per 
second  by  displaying  every  6th  data  point.  Ele  ation  data  was  exaggerated  in  order  to 
provide  a  more  hilly  appearance,  with  terrain  coloring  made  a  function  of  elevation.  Flat 
shading  was  implemented  instead  of  Gouraud  shading  in  order  to  provide  a  “checkerboard 
effect”  aiding  motion  detection.  FOGM  implemented  tri'dal  culling  by  establishing  a 
recungular  bounding  volume  based  upon  the  ’  'hide’s  heading.  Polygons  outside  this 
volume  were  culled. 

2.  Vehide  (VEH)  Simulator 

VEH,  an  extension  of  the  FOGM  simulator,  was  also  implemented  on  an  IRIS 
3120  and  completed  in  December  1987.  The  FOGM  terrain  rendering  algorithm  was 
modified  to  include  a  more  refined  Field  of  View  (FOV)  culling  algorithm.  Full  3D  culling 
often  uses  clipping  planes  to  form  a  four  sided  “pyramid  of  vision”  with  the  axis  of  the 
pyramid  along  the  vehicle's  path.  VEH  utilized  the  left,  right,  and  far  clipping  planes.  VEH 
subjected  FQGM's  bounding  volume  to  further  culling  based  up(>n  a  narrow  or  wide  field 
of  view.  Only  those  polygons  within  the  bounding  volume,  and  within  the  FOV  were  sent 
through  the  graphics  pipeline.  Vehicle  roll  (Viewer  “twist”)  was  not  incorporated  in  cither 
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FOGM  cr  VEH  ihus  eliminating  the  need  for  more  than  three  clipping  planes.  FOGM’s 
FOV  cullihg  was  strictly  a  function  of  rotation  about  the  screen’s  “y”  axis  (vehicle 
heading).  A  further  contribution  of  VEH  was  the  in'rorporation  of  SINE,  COSINE,  and 
TANGENT  lookup  tables  instead  of  function  calls.  Speed  improvements  of  over  1{XX)% 
were  noticed  in  some  cases  when  using  the  tables  instead  of  the  math  library  (Oliver  1988). 

3.  Moving  Platform  Simulator  (MPS) 

The  MPS  series  evolved  from  the  VEH  and  FOGM  simulators.  Significant 
improvcmc.:ts  were  made  to  the  gridded  lenain  algori.hms  previously  used.  Implemented 
on  an  IRIS  4D/70GT  workstation  with  hardware  supporting  the  z-buffer  algorithm,  the 
need  for  the  Painter’s  algorithm  for  hidden  surface  elimination  was  removed. 

MPS  incorporated  three  resolution  levels,  and  variable  field  of  views.  The 
highest  resolution  level  extends  out  to  .a.  distance  which  is  a  function  of  the  field  of  view. 
The  resolution  is  then  halved  and  extended  out  2000  meters,  halved  again  out  to  the 
horizon.  Gaps  occur  at  the  seams  between  resolution  levels  as  extra  vertices  exist  on  the 
high  resolution  side  of  the  seam.  To  eliminate  this  problem,  extra  polygons  were  drawn  to 
fill  the  holes.  These  polygons,  termed  “skins”,  were  vertical  planes  which  were  often 
perpendicular  to  the  actual  terrain.  A  drawback  to  this  method  was  that  as  the  seams 
changed  location  with  vehicle  movement,  a  slight  flickering  would  occur  due  to  the 
insertion  and  deletion  of  these  venical  surfaces. 

Whereas  previous  simulators  were  limited  to  the  10  by  10  kilometer  area  of  Fon 
Hunter  Ligget,  MPS  had  the  ability  to  display  gridded  terrain  databases  containing  any  grid 
point  .spacing. 

4.  Forward  Observer  Simulation  Trainer  (FOST) 

POST  (Drummond  1989)  utilized  DMA  Level  I  Digital  Terrain  Elevation  Data  to 
generate  coordinates  in  the  Military  Grid  Reference  System  (MGRS).  Although  FOST 


5 


adapted  the  MPS  terrain  rendering  algorithm,  minor  modifications  included  switching  from 
polygon  primitives  to  inesh  primitives  to  increase  performance.  This  decision  was  based 
upon  performance  measurements  in  MPSn  (Winn  June  89),  the  second  simulator  in  the 
MPS  scries.  Paragraph  6  describes  mesh  drawing  in  more  detail. 

5.  Command  and  Control  Workstation  of  the  Future  (CCWF) 

The  CCWF  (Harris  1988)  was  initiated  at  the  Naval  Postgraduate  School  as  part 
of  an  effort  to  provide  a  3D  real  time  interface  for  the  Battle  Group  Commander.  In  order 
to  enhance  real  time  capabilities,  CCWF  also  incorporated  variable  terrain  resolution 
strategy.  While  MPS  adapted  binary  reduction  between  resolution  levels,  CtTWF  decreased 
resolution  levels  from  100  yard  spacing  to  1200  yard  spacing  and  finally  12000  yard 
separation  at  the  lowest  resolution  level.  Such  a. strategy  provided  a  greater  reduction  of 
polygons  at  lower  resolutions  but  provided  a  more  dynamic  terrain  change  at  the  seams.  In 
order  to  maintain  three  separate  resolution  levels  of  data,  separate  terrain  databases  were 
created  for  the  various  resolutions.  While  increasing  data  storage  requirements,  the 
reduction  of  run  time  calculations  resulted  in  an  increased  frame  rate. 

To  solve  the  boundary  problem,  CCWF  utilized  the  “skirt”  method  developed  in 
the  MPS  series  to  draw  seams  between  resolution  levels.  All  three  resolution  levels  are 
drawn  from  the  vehicle,  resulting  in  the  high  resolution  carpet  being  drawn  over  lower 
resolution  carpets.  The  net  effect  was  that  lower  resolution  terrain  would  “cut  through” 
valleys  of  the  higher  resolution  terrain. 

The  CCWF  was  the  first  NPS  Simulator  to  draw  data  using  DMA’s  Digital  Terrain 
Elevation  Data.  The  area  of  operations  centered  around  the  Sea  of  Japan. 

6.  CCWF,  Subsurface  and  Periscope  Views 

In  follow-up  work  to  the  CCWF  (Weeks  1989),  a  triangular  mesh  drawing  routine 
was  incorporated  in  addition  to  the  polygon  drawing  routine.  By  reducing  the  number  of 


vertices  required  to  be  sent  through  the  graphics  pipeline  (4  instead  of  6  per  triangle  pair), 
a  50%  speed  increase  in  graphics  frame  rate  was  obtained.  When  using  mesh  drawing 
routines,  vertex  normals  instead  of  polygon  normals  were  generated  resulting  in  a 
smoother,  more  realistic  appearance.  The  “skirt”  method  of  filling  resolution  seams  did  not 
work  as  well  when  using  the  “mesh”  mode.  Since  the  skirt  lighting  normals  were 
horizontal,  skirt  flickering  discovered  in  MPS  became  very  pronounced  as  surrounding 
lighting  normals  were  essentially  vertical.  The  polygon  (checkerboard)  method  was  left 
available  as  an  option.  Without  terrain  features,  motion  on  level  surfaces  is  often  difrlcult 
to  detect  without  the  checkerboard  effect. 

A  primary  concern  is  the  storage  requirement  for  CCWF  lighting.  To  adequately 
light  the  terrain,  vertex  normals  are  computed  at  start-up.  Thus  terrain  database 
requirements  grew  from  2.88  megabytes  to  well  over  21  megabytes.  An  anempt  was  made 
;o  compute  normals  dynamically,  however,  a  50%  performance  reduction  degraded  the 
system  real  time  performance  capabilities. 

A  recommendation  for  future  research  was  to  incorporate  control  surfaces  into  the 
ships,  such  as  rudders.  Initial  work  on  the  AUV  NPS  Simulator  was  undertaken  with 
CCWF  requirements  well  understood;  specifically  applicable  to  CCWF  arc  (1)  use  of 
control  surfaces  to  drive  vehicle;  (2)  elimination  of  requirement  to  use  skins  at  resolution 
boundaries;  (3)  incorporation  of  sonar,  (4)  development  of  vehicle  control  panel. 

7.  NPSNET 

NPSNET  (Zyda,  Pratt  1990)  is  the  Naval  Postgraduate  School’s  low-cost  version 
of  the  DARPA  SIMNET  System.  While  refining  many  of  the  NPS  terrain  rendering 
algorithms,  NPSNETs  enhancements  include  incc*poration  of  cultural  terrain  features 
such  as  ground  cover,  man-made  structures,  and  terrain  texturing.  Research  continues  on 


optimal  display  of  such  features  on  sloped  and  variable  resolution  terrain  while  maintaining 
real-time  updates. 

B.  AUV  SIMULATOR  DEVELOPMENT 

1.  Use  of  SDV  Hydrocoefficients 

The  (Mriginal  NPS  non-graphical  simulation  of  an  underwater  vehicle  can  be  found 
in  (Boncal,  1987).  ,  Utilizing  basic  submarine  equations  of  motion  (Gertler  1967),  with 
modifications  to  reflect  the  geometry  of  the  U.S.  Navy’s  Swimmer’s  Delivery  Vehicle 
(Smith  1978),  Boncal  designed  a  controller  to  control  rudders,  bow  planes,  and  stem  planes 
based  upon  the  vehicle’s  predicted  dynamics. 

2.  Origins  of  NPS  Auv  Simulator 

The  initial  3D  graphics  submarine  simulator  (MacPherson  1988)  consisted  of  a 
submersible  which  utilized  a  rudder,  stem  planes,  and  a  single  screw.  Movement  of  these 
control  surfaces  imparted  pitch,  yaw,  and  speed  to  the  vehicle.  Simple  dynamics  were 
employed  to  derive  appropriate  vehicle  responses.  Actual  submarine  dynamics  were  not 
modeled  as  the  simulator  was  utilized  to  test  mission  path  planning  algorithm’s  only. 

3.  NPS  AUV-SIMl 

The  current  AUV  graphics  simulator  is  an  extension  of  a.  graduate  graphics  project 
by  D.  Marco,  R.  Rogen,  aiul  M.  Schwartz  (Zyda,  McGhee,  Kwak  1990).  AUV-SIMl  was 
the  first  graphics  simulator  to  utilize  the  Swimmer’s  Delivery  Vehicle  equations  of  motion 
as  modified  by  R.  Boncal  (Boncal  1987).  Intended  to  model  the  NPS  Autonomous 
Underwater  Vehicle,  the  simulator  demonstrated  realistic  submarine  dynamic  behavior. 
The  simulator  incorporated  a  nxruse  pand  to  make  adjustments  to  rpm,  rudder,  and  bow 
planes.  The  environment  was  a  120  ft  x  60ft  x  8ft  swimming  pool,  the  vehicle  drawn  as  a 
six  foot  submersible  with  twin  screws,  stem  rudders,  bow  and  stem  planes. 
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Communications  code  was  added  to  receive  autopilot  command  controls  fron"  a  Symbolics 
LISP  machine  (Nordman  1989). 

4.  NPS  AUV-SIM2 

The  appearance  of  the  graphics  AUV  was  modified  to  reflect  the  actual  AUV 
being  built  by  the  Naval  Postgraduate  School.  Essentially  symmetric  in  shape,  AUV-SIM2 
has  eight  control  surfaces  consisting  of  bow  planes,  stem  planes,  bew  rudders,  and  stem 
rudders.  The  swimming  pool  was  redesigned  to  reflect  the  appearance  of  the  NPS 
swimming  pool  where  initial  testing  of  the  actual  vehicle  would  take  place.  The  basic  “C 
code  was  further  modulized.  The  Mission  Planning  Expert  System  was  developed  on  the 
Symbolics  Lisp  Machine  using  the  KEE  Expen  Shell  resulting  in  some  modifications  to  the 
“C”  communications  code  (Ong  1989).  Although  tlie  vehicle’s  appearance  reflected  the 
actual  AUV,  the  dynamics  and  geometry  reflected  the  asymmetrical,  much  larger  SDV. 

C.  NPSAUV.m 

NPS  AUV'Dl  is  a  result  of  this  thesis.  While  making  minor  upgrades  to  the  vehicle’s 
appearance,  the  primary  contributions  were  a  reengineering  of  the  software  to  encapsulate 
the  AUV  as  a  rigid  body  using  object  oriented  programming  techniques  prototyped  in  LISP. 
The  equations  of  motions  and  hydrodynamic  coefficients  were  modified  to  reflect  the 
geometry  of  the  NPS  AUV  rather  than  the  SDV.  Fuithermare,  the  drag  coefficients  and 
added-mass  coefficients  are  no  longer  ’’hard  coded”  into  the  program,  but  are  parsed  from 
an  external  file  at  the  program’s  initiation.  These  coefficients  are  modifiable  on-line  so 
adjustments  can  easily  be  made  and  tested.  The  revised  coefficients  can  then  be  saved  to  an 
external  file  for  further  refinement.  The  Monterey  Bay  environment  was  incorporated  to 
allow  more  expansive  testing  of  the  search  algorithms  and  testing  of  system  dynamics  that 
can  not  be  tested  within  the  constraints  of  the  NPS  Pool. 
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A  record  cq)ability  exists  to  develop  a  script  that  can  be  used  by  the  actual  vehicle 
during  testing.  A  replay  capability  exists  to  reexamine  missions,  or  to  test  externally 
generated  scripts:  A  sliding  scale  enables  the  speed  of  replay  to  be  adjusted.  On  line 
stripchaits  display  changes  in  velocities  and  accelerations  to  be  displayed  along  all  axes. 
The  user  interface  was  designed  to  allow  to  display  the  vehicle’s  orientation  (pitch. 


heading,  and  roll). 


in.  GRAPHICS  PIPELINE  LOAD  REDUCTION  TECHNIQUES 


The  Silicon  Graphics  4D/240GTX  contains  four  MIPS  R3000  CPU’s  and  R3010  RISC 
components.  The  CPUs  run  at  25mhz  and  together  execute  approximately  80  million 
instructions  per  second  (MIPS)  achieving  four  double  precision  Mflops  (Ackley 
1989).  The  graphics  architecture  is  divided  into  four  subsystems:  the  transformation 
subsystem,  scan-con\ersion  subsystem/aster  subsystem,  arid  display  subsystem.  Of 
interest  here  is  the  transformation  subsystem,  for  this  is  where  the  limit  is  set  on  the  number 
of  vertices  which  can  b^  generated  per  second. 

The  transformation  subsystem,  called  the  Geometry  Engine,  is  capable  of  processing 
400,000  vertices  per  second.  A  single  vertex  transformation  requires  approximately  100 
FLOPS.  To  achieve  a  frame  rate  of  10H2L,  for  example,  wc  must  attempt  to  pass  less  than 
40,(XX)  vertices  per  frame.  30  %  of  the  Geometry  Engine’s  work  is  in  performing  vertex 
transformations,  with  the  remaining  work  performing  operations  such  as  lighting 
calculations  and  noimal  transformations.  Since  the  programmer  can  directly  influence  the 
total  number  of  vertices  sent  to  the  Geometry  Engine,  it  is  often  desirable  to  employ  venex 
reduction  techniques  when  the  goal  is  real  time  graphics  display.  Some  of  the  techniques 
used  in  the  NPS  AUV  simulator  are  described  below. 

A.  MESH  DRAWING  ROUTINES 

In  order  to  draw  the  entire  Mcnteiey  Bay  database  as  polygons  (triangles),  each 
internal  vertex  needs  to  be  sent  six  times,  once  for  each  polygon  that  shares  the  vertex.  As 
demonstrated  in  CCWF,  the  graphics  library  function  frgnrmerAf)  can  gready  improve 
graphics  pipeline  efficiency.  By  drawing  the  area  as  a  Series  of  mesh  strips,  each  internal 
vertex  needs  to  be  sent  only  twice  to  represent  the  six  adjacent  polygons,  as  illustrated  in 
Rgurc  3.1.  The  vertex  information  is  maintained  in  two  “vertex  registers”  within  the  IRIS- 


11 


4D.  As  a  result,  the  total  number  of  vertices  required  drops  from  over  300,000  to  slightly 
oyer  100,000.  Since  the  Geometry  Engine  is  capable  of  400k  vertices  per  second,  it  can 
pass  135k  triangles  per  second  when  using  mesh  drawing  routines. 

The  IRIS-4D  VGX  models  contain  three  vertex  registers,  enabling  the  vertices  to  be 
represented  as  part  of  a  quadrilateral  using  bgnqstrip().  TI  ;  function  increases 

the  efficiency  of  the  Geometry  Engine  even  further,  as  100k  quadrilaterals  (200k  triangles) 
can  be  drawn  per  second.  In  addition,  “Q-mesh”  provides  superior  shading  and  lighting 
over  “T-mesh”(Graphics  Library  1 990). 


Figure  3.1  Mesh  Drawing  Auvantage 


B.  VARIABLE  TERRAIN  RESOLUTION 


Both  CCWF  and  MPS  demonstrated  the  importance  of  variable  terrain  resolution. 
Since  the  number  of  data  points  available  for  display  increase  by  with  the  square  of  the 
distance  from  the  observer,  it  is  essential  that  such  a  reduction  be  incorporated.  By  limiting 
the  degree  of  the  resolution  changes  and  increasing  the  number  of  resolution  changes,  the 
NPS  AUV  Dynamic  Simulator  is  able  to  reduce  the  rate  of  vertex  increase  from  O  (N  )  to 
nearly  0  (N) ,  with  the  later  being  approached  as  the  number  of  resolution  levels  is 
increased.  A  major  concern  with  multiple  resolutions  is  “seam  handling”,  or  the  smooth 
transition  from  one  resolution  to  another.  The  chapter  on  the  VTRA  (Variable  Terrain 
Resolution  Algorithm)  addresses  this  issue.  Figure  3.2  depicts  the  effect  of  decreasing  the 
resolution  in  a  binary  fashion,  while  increasing  the  number  of  resolution  levels  between  the 
observer  and  the  horizon. 

C.  POLYGON  CULLING 

The  VTRA  can  be  applied  in  conjunction  with  culling.  The  merits  of  culling  have  been 
demonstrated  in  numerous  NPS  simulators.  As  an  example  of  the  power  of 
culling,  consider  a  60  degree  Field  of  View.  If  polygons  outside  the  FOV  can  be  culled, 
then  a  lessened  load  is  placed  on  the  graphics  pipeline.  Very  efficient  mesh  drawing 
routines  now  exist,  so  one  must  weigh  the  CPU  overfiead  required  of  culling,  against  the 
efficiency  of  the  Geometry  Engine.  Often,  a  “rough  clip"  is  superior  to  fine  calling  since 
the  later  must  often  be  done  in  the  mesh  ^wing  loop,  with  culling  conditions  checked 
against  every  vertex.  Fine  culling  was  experimented  with  in  the  NPS  AUV  Simulator,  and 
performance  was  actually  lower  than  that  with  the  “quadmesh”  drawing  without  culling. 
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Figure  3.2  Variable  Resolution  Effects  on  Vertex  Count 
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Figure  3.3  is  an  aerial  viewer  of  the  Monterey  Bay.  The  Submarine  heading  is  045  degrees 
with  a  field  of  view  of  +/-  45  degrees.  Data  outside  the  FOV  is  ct^ed 


The  culling  in  the  NFS  Simulator  is  similar  to  the  <XWF  culling  algorithm.  The  terrain 
is  divided  into  four  sectors,  Noith,  South,  East,  and  West.  The  origin  is  at  die  viewer’s 
location  (in  NFS  AUV  Simulator,  the  observer  need  not  be  at  the  vehicle).  The  view 
direction  is  the  vehicle’s  heading,  or  the  observer’s  viewing  azunuth.  Sine  and  Cosine 
lookup  tables  are  created  the  first  time  the  culling  routine  is  activated.  VTRA  has  the  notion 


of  minimum  and  maximum  rows  and  columns,  usually  the  limit  of  the  database.  The  NFS 
AUV  Simulator  simply  uses  the  viewing  azimuth  to  further  constrain  these  limits.  For 
example,  if  the  observer  is  viewing  towards  the  East  sector,  then  the  minimum  column  can 
immediately  be  increased  to  the  observer’s  column.  The  maximum  column  is  already  set 
by  the  horizon  limitations.  Therefore,  the  only  requirement  is  to  adjust  the  maximum  and 
minimum  rows  using  the  view  direction,  right  and  left  clipping  angles,  horizon,  and 
trigometric  lookup  tables.  Figure  3.4  contains  the  pseudocode  for  culling  techniques 
utilized  in  the  NFS  AUV  Simulator. 

Since  the  NFS  AUV  Simulator  is  essentially  a  flight  simulator  and  capable  of  angular 
accelerations  along  all  three  axes,  further  culling  was  attempted  based  upon  sine  of  the 
pitch  in  conjunction  with  the  altitude  and  the  sine  of  the  roll  in  conjunction  with  the  vertical 
field  of  view,  Althoug*'  this  was  relatively  easy  to  accomplish,  the  savings  in  vertex 
generation  could  not  match  the  additional  mathematics  involved  and  system  performance 
declined.  Therefore,  culling  is  based  upon  rotation  around  the  system’s  “y”  axis  only 
(heading).  With  culling  activated,  the  NFS  AUV  Simulator’s  frame  rate  increased  by  2  to 
4  firames  per  second  depending  on  number  of  resolution  levels  and  horizon. 
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if(NORTH_SECTOR)  | 
minrow  =  viewer_row; 
maxrow  =  maximum_row; 

mincol  =  viewer_col  -  horizon  *tan<;ieft_clipping_azimuth); 
maxcol  =  viewer_col  +  horizon  *  tan(right_clipping_.azimuth); 

) 

if(SQUTH_SECrOR)  { 
minrow  =  mihimum_row; 
maxrow  =  viewer_row; 

mincol  =  viewer_col  -  horizon  *  tan(right_clipping_azimuth); 
maxcol  =  viewer_coI  -  horizon  *  tan(lefit_clipping_azimuth); 

} 

if(EAST_SECTOR)  { 

minrow  =  viewer_row  +  horizon  /  tan(right_clipping_azimath); 
maxrow  =  viewer_row  +  horizon  /  tan(left_clipping_azhnuth); 
mincol  =■  viewer_col; 
maxcol  =  maximum_col; 

} 

if(WEST_SECrOR)  { 

minrow  =  viewer^row  -  horizon  /  tan(left_clipping_azimuth); 
maxrow  =  viewer_row  -  horizon  /  ■;an  (right^clipping^azimuth); 
mincol  =  minimum_col; 
maxcol  *  viewcr_col; 

I  •  ,  : 

Figure  3.4  C^lipping  Pseudocode 

The  row  end  column  constraints  are  reset  by  thv;  clipping 
routine,  and  are  utilized  by  VTRA  for  generating  terrain. 
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IV.  VARIABLE  TERRAIN  RESOLUTION  ALGORITHM 


A.  BACKGROUND 

As  shown  in  the  previous  chapter,  there  is  a  need  to  display  grid  terrain  at  various 
resolutions  if  real  time  simulation  is  the  goal.  The  variable  terrain  resolution  algorithm 
(VTRA)  was  initially  conceived  while  conducting  research  on  aerial  view  techniques  for 
the  Command  and  Control  Workstation  of  the  Future,  and  is  fidly  incorporated  into  the 
NFS  AUV  Simulator.  The  algorithm  assumes  that  highest  visibility  terrain  should  be  drawn 
around  the  observer,  and  that  the  observer’s  position  be  selectable,  whether  inside  or 
outside  a  vehicle.  The  formula  requires  four  inputs;  the  observer’s  horizon,  the  number  of 
resolution  levels  required,  the  maximum  resolution  level  required,  and  system  performance 
as  measured  by  “delta  time”  (the  inverse  of  the  system  frame  rate). 

Based  upon  the  input  parameters,  VTRA  determines  a  grid  density  for  the  lowest 
resolution  terrain,  and  draws  this  terrain  from  the  horizon  to  1/2  horizon.  The  horizon  is 
then  reset  to  the  1/2  horizon,  and  the  grid  density  doubled.  The  function  is  called 
recursively  with  the  new  parameters  until  maximum  density  is  achieved.  This  density  is 
then  drawn  to  the  observer  and  the  algorithm  stopping  condition  achieved.  Figure  4.1 
contains  the  pseudocode  for  the  algorithm  as  used  in  the  NFS  AUV  Simulator. 


/*  vehicle  is  a  stnicture  containing  the  vehicle’s  state,  i.e.,  orientation,  position  */ 

show_terrain(vehicle) 

Veh_ptr  vehicle; 

{ 

int  stan[0]  =  vehicle’s  X  position  on  grid; 
int  start!  1]  =  vehicle’s  Y  position  on  grid; 
int  horizon  =  128; 
int  vert_spacing  =16; 
int  njax_rcs_level  =  1; 

show2_tcrTain(vehicle,  start,  horizon,  rcs_level); 

} 

show2_terrain(Veh_ptr  vehicle,  int  star’(2),  int  horizon,int  vert_spacing) 

{ 

if(vert_spacing  =  max_res_level)  { 
draw_teiTain_from_horizon_io_vchicle_at_currcnt_rcs_levcl(); 
else  { 

draw_terrain_fiponi_horiron_to_I/2_horizon_at_CTirrent_rcs_Ievel(); 

)  , 

Figure  4.1  VTRA  Pseudocode 
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B.  ADVANTAGES  OF  USING  VTRA 

1.  Compatible  with  DMA  Terrain  Database 

VTRA  will  work  with  any  size  two  dimensional  array  of  grid  data.  The  value  of 
using  authentic  DMA  tqrain  data  has  been  demonstrated  in  numerous  NPG  simulators. 
The  algorithm  was  developed  using  Monterey  Bay  terrain  data  received  counesy  of  the 
Monterey  Bay  Research  Institute  (MBARI).  Figure  4.2  depicts  the  data  structure  which  was 
originally  in  values  of  positive  meters  and  converted  to  negative  feet.  When  the  NFS  AUV 
Simulator  is  activated,  the  function  scan_zj>ay()  reads  the  data  into  a  222  x  245  x  3  array. 
The  X  and  Y  dau  is  generated  based  on  vertex  spacing.  Since  above  ground  terrain  is 
represented  with  zero  elevation  data,  a  random  number  generator  assigns  positive  values  to 
present  a  discernible  coastline.  Currently,  work  is  underway  to  merge  Monterey  Bay 
Subterrain  data  with  DMA  terrain  data  for  use  with  VTRA  and  subsequent  aerial  and 
subsurface  views  of  the  Monterey  Bay  Coast 
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2.  Less  Storage  Requirements 

VIRA  uses  an  array  of  venex  normals  generated  during  program  initialization  to 
perform  lighting  calculations.  After  the  terrain  data  array  is  parsed,  the  NFS  AUV 
Simulator  uses  the  function  compute  bay  jiormalsO  to  generate  vertex  normals.  Using  the 
four  adjacent  vertices,  normals  for  the  four  adjoining  polygons  are  computed  From  these 
four  normals,  a  final  unit  vertex  normal  is  generated.  Unlike  previous  simulators  using 
variable  resolution  strategies,  there  is  no  need  to  precompute  and  prestore  various 
resolution  data,  only  one  data  set  need  to  be  stored. 

3.  VTRA  improves  DMA  terrain  rendering  efficiency 

CCWF  research  (Weeks  1989)  identified  the  amount  of  data  required  to  display 
terrain  out  to  the  horizon,  typically  26  nautical  miles,  as  a  major  concern.  Using  DMA 
1201  X  1201  terrain  with  100  yard  spacing  as  an  example,  we  apply  the  VTRA  to  display 
the  dau  base  out  to  26  nautical  miles  without  using  100%  of  the  database. 

Placing  the  observer  in  the  center  of  the  grid,  assume  a  horizon  of  512  data  points 
(51,200  yards  or  25.5  nm),  we  apply  the  algorithm  before  field  of  view  culling.  Displaying 
all  the  data  at  highest  resolution  requires  (1024  x  1024)  or  1 .2m  vertices.  Displaying  all  the 
data  at  1/4  resolution  requires  (256  x  256)  or  64k  vertices.  With  the  VTRA  formula,  and 
using  5  resolution  levels,  only  16k  vertices  are  required  while  providing  maximum 
resolution  out  to  3200  yards.  This  represents  less  than  2.0%  of  the  total  available  vertices. 
By  applying  4  resolution  levels,  the  area  of  highest  resolution  is  extended  out  to  6400  yards 
with  a  vertex  count  of  26k,  less  than  3%  of  the  total  available  vertices. 

When  using  DMA  terrain  data,  one  concern  is  when  should  another  geographic 
cell  be  read  from  disk  into  memory.  By  extending  the  horizon,  at  low  resolutions,  a  distance 
that  is  a  function  of  the  vehicle  speed  and  the  amount  of  time  to  recover  data  from  storage, 
the  htffizon  boundary  can  act  as  a  “trigger”  to  initiate  reading  of  a  particular  cell. 
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The  flexibility  of  VTRA  enables  the  programmer  to  emphasize  either  resolution 
or  horizon.  A  geologist  scanning  a  desert  from  the  air  would  expect  to  see  geological 
structures  in  greater  detail  as  he  approached  the  desert  floor.  As  he  descends,  his  horizon 
would  decrease  with  the  square  root  of  the  altitude. 

There  are  Uuee  factors  affecting  the  total  vertex  count  using  VTRA:  horizon, 
total  number  of  resolution  levels,  and  maximum  resolution  level.  Each  of  these  factors  is  a 
VTRA  input  parameter. 

The  horizon  is  the  number  of  data  points  extending  from  the  observer  that  will  be 
displayed  on  the  screen.  Data  within  the  horizon  is  depicted  after  appljnng  proper  spacing. 
The  horizon  must  always  be  a  power  of  2,  i.e.,  64,  128, 256,  etc..  The  data  spacing  factor 
must  also  be  passed  as  a  parameter  so  the  algorithm  can  convert  the  horizon  to  geographical 
coordinate!  Decreasing  the  horizon  increases  system  performance. 

The  total  number  of  resolution  levels  is  only  limited  by  available  horizon.  The 
lowest  resolution  extends  from  1/2  horizon  to  horizon,  the  next  lowest  from  1/4  horizon  to 
1/2  h<»izon.  The  binary*  reduction  continues  recursively  until  the  maximum  resolution  level 
is  reached.  Data  from  the  observer  to  the  innermost  horizon  is  depicted  at  maximum 
resolution  level  Increasing  the  total  number  of  resolution  levels  increases  workstation 
performance,  and  decreases  the  total  area  of  maximum  resolution. 

The  maximum  resolution  let'el  determines  the  density  that  terrain  will  be  rendered 
closest  to  the  observer.  For  example,  at  resolution  level  one,  every  data  point  is  represented; 
at  resolution  level  two,  every  other  data  point;  and  at  resolution  level  four,  every  fourth 
point  Notice  that  there  is  no  resolution  level  three,  as  VTRA  relies  upon  a  binary  reduction 
of  terrain  resolutions.  Each  outer  resolution  area  is  1/2  the  density  of  the  inner  resolution 
area,  with  the  innermost  resolution  area  representing  the  starting  density.  Theiefore; 
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lowering  the  maximum  resolution  level  from  one,  to  two  or  four,  will  greatly  reduce  total 
vertex  requirements. 

The  defaul  parameters  of  the  NFS  AUV  Simulator  are  a  horizon  of  256  data 
points,  total  number  of  resolution  levels  of  four,  and  a  maximum  resolution  level  of  one. 
Figure  4.3  depicts  a  view  bf  Monterey  Bay  from  an  altitude  of  80  nautical  miles.  Figure 
4.4  shows  the  bay  drawn  as  a  wiremesh  with  four  VTRA  resolutions . 


Figure  4  J  Filled  View  of  Monterey  Bay 


Figure  4.4  Four  Resolutions  of  Monterey 

4.  VTKA  resolution  can  be  adjusted  automatically 

Since  the  three  controlling  factors  are  input  parameters,  the  programmer  can  elect 
to  create  a  function  to  automatically  control  these  values.  NFS  AUV  Simulator  has  such  a 
function,  auto  _resolution(),  which  is  activated  from  the  terrcun  control  panel. 

The  luv  horizon  is  a  function  of  its  “absolute  altitude”,  i.e.,  height  above  the 
terrain.  As  th :  vehicle  climbs,  the  horizon  doubles  at  programmed  intervals.  As  the  vehicle 
approaches  “mountainous  terrain”,  such  as  the  Monterey  Bay  Canyon  wall,  the  horizon  will 
decrease  by  half  to  provide  better  resolution  of  the  terrain. 

The  sjra  of  maximum  resolution  beneath  the  vehicle  is  inversely  proportional  to 
the  vehicle  hprizon,  i.e.,  as  extra  vertices  are  portrayed  by  extending  the  horizon,  a 


reduction  of  vertices  directiy  below  the  vehicle  takes  place.  The  trade-off  is  nearly  equal  so 
system  performance  remains  almost  the  same. 

The  third  factor,  number  of  resolution  levels,  is  adjusted  as  a  function  of  system 
performance.  The  instant  a  decrease  of  performance  is  detected,  whether  the  cause  is 
internal  or  external  to  the  program,  the  number  of  resolution  levels  is  increased  easing  the 
graphics  pipeline  load.  Conversely,  if  the  system  is  running  efficiently,  the  number  of 
resolutions  is  decreased,  thus  extending  the  range  of  higher  density  terrain  rendering.  The 
number  of  resolution  levels  becomes  a  function  of  workstation  performance. 

5.  VTRA  Adjusts  to  Workstation  Upgrades 

By  adjusting  the  input  parameters  as  a  function  of  system  performance  as  was 
done  in  the  NFS  AUV  Simulator,  discussed  above,  higher  performance  architectures  using 
VTRA  will  maintain  the  real  time  depiction,  and  terrain  rendering  will  automatically 
improve.  There  is  no  need  to  rewrite  the  program  since  VTRA  can  automatically  provide 
more  realistic  terrain  rendering. 

C.  ADDITIONAL  VTRA  DRAWING  CONSIDERATIONS 
1.  Seam  Filling 

As  seen  throughout  the  development  of  vehicle  simulators  incorporating  a 
variable  resolution  scheme,  making  a  smooth  transition  from  one  resolution  to  another  has 
beeti  9  problem  with  various  solutions.  Additional  polygon  generation  and  normal 
ca.culations  required  to  “fill  the  seams”  can  degrade  system  performance.  VTRA  solved 
this  problem  by  sta^ng  within  the  binary  reduction  recursive  routine.  NFS  AUV  Simulator 
seam  “stitching”  functions  will  work  at  any  horizon.  Rather  than  Ailing  holes  after  the 
terrain  has  been  generated,  the  seams  are  pan  of  the  terrain  rendering  process.  Mesh 
drawing  routines  always  require  an  even  number  of  vertices  from  within  the  mesh  function. 


VTRA’s  stitching  requires  two  vertices  per  seam  for  each  vertex  row  scanned,  ensuring  this 
requirement  is  met.  Every  stitched  vertex  uses  its  precomputed  normal  for  generating 
proper  lighting  effects.  As  a  result,  seams  can  not  be  detected  as  seen  in  the  various  terrain 
pictures  throughout  this  paper. 

2.  Geographic  Referencing 

When  drawing  terrain  at  various  resolutions,  the  choice  of  which  points  to 
represent  should  be  a  function  both  relative  to  the  observer  ann  relative  to  actual  geographic 
position.  In  the  original  NFS  AUV  design,  the  points  displayed  were  relative  only  to  the 
observer.  As  a  result,  resolution  level  4,  for  example,  would  “shift”  the  vertices  displayed 
resulting  in  a  rippling  movement  as  the  vehicle  progress^.  Steady  terrain  was  generated 
by  depicting  only  those  vertices  whose  row  %  four  and  col  %  four  equaled  zero. 
Geographic  referencing  is  also  required  in  the  seam  drawing  algorithm  to  ensure  smooth 
blending  from  one  resolution  to  another. 

3.  Inner  Horizon  Blocking  Of  Draw  Routine 

Previous  simulators  discovered  problems  when  trying  to  place  a  small  “high 
resolution  carpet”  over  a  lower  resolution  such  as  valleys  being  “sliced”  by  the  underlying 
lower  re^lution  plane.  To  ensure  this  doesn’t  happen,  and  to  greatly  reduce  vertex 
generation,  drawing  of  all  data  from  horizon/2  to  the  observer  is  blocked,  for  each  horizon 
in  the  recursive  call  except  for  the  highest  resolution  which  continues  all  the  way  to  the 
observer. 

4.  Viewer  Perspective 

Resolution  should  be  based  on  the  observer  position,  not  a  vehicle’s  position. 
Therefore,  the  program  should  track  the  observers  coordinates,  as  these  are  the  coordinates 


the  VTRA  will  base  the  recursive  stopping  condition,  i.e.,  the  center  of  high  resolution 
display. 

5.  TERRAIN  FEATURES 

Drawing  with  mesh  routines  and  lighting  has  generated  realistic  looking  terrain  in 
recent  simulators.  However,  without  the  checkerboard  effect,  motion  is  difficult  to  sense. 
Terrain  structures  or  vegetation  can  help  provide  this  effect  This  is  evident  in  NPSNET 
which  uses  ground  cover  and  structures  to  aid  with  the  sense  of  motion. 

While  displaying  features  on  highe.st  resolution  terrain  does  not  cause  a  problem, 
at  lower  resolution  the  item  may  rest  on  a  vertex  not  displayed,  causing  polygons  to  slice 
through  the  structure.  A  possible  solution  in  VTRA  is  to  modify  the  algorithm  to  display 
highest  resolution  terrain  “patch”  where  any  structure  exists.  The  row  scanning  process  can 
make  this  an  easily  incorporated  feature. 

D.  VTRA  BENCHMARKING 

These  figures  were  taken  firom  the  NFS  AUV  Simulator  with  the  Simulator's  “culling” 
feature  disabled.  The  vehicle  was  operated  from  a  “Cockpit  View”  so  that  the  vehicle’s 
polygons  were  not  drawn.  The  Simulator  was  run  on  a  Silicon  Graphics,  Inc.,  IRIS  4D/ 
240VGX  Workstation  rated  SO  MIPS  and  16  M  FLOPS  using  all  four  processors.  The 
benchmarks  were  taken  using  single  processor  mode. 

Figure  4.5  shows  the  effect  of  decreasing  the  maximum  resolution  levels  has  on  frame 
rate.  These  curves  were  obtained  using  a  horizon  of  128  data  points  (approximately  14  nm). 
Since  128  may  only  be  reduced  six  times  while  maintaining  sufficient  vertices  to  generate 
a  mesh  at  the  highest  resolution  level,  frame  rate  begins  to  decline  after  six  reductions. 
Each  reduction  of  maximum  resolution  requirement  gains  an  extra  3  to  4  frames  p^  second. 
The  effect  of  Culling  shows  an  extra  2  to  3  frames  per  second  when  using  five  resolutions 
with  a  maximum  resolution  of  four. 
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Figure  4.6  contains  a  table  of  measurements  of  frame  rates  for  various  horizon  and 
P'lmber  of  resolution  combinations. ,  This  table  proved  useful  in  developing  the  AUV 
auto_resolution  algorithm.  Measurements  were  taken  using  a  maximum  resolution  of  one 
(every  data  point  displayed  in  innermost  horizon).  These  figures  were  utilized  when 
developing  the  aiao_resolution()  function  for  the  NFS  AUV  Simulator.  Figure  4.7  provides 
a  view  of  the  filled  terrain  from  an  observer  perspective. 


Figure  4  J  Varying  the  Max  Resolution 
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a  frame  rate  of  approximately  10  may  be  achieved  for  most  horizons. 
Figure  4.6VTRA  Performance  Figures 
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V.  AUV  DATA  STRUCTURE 


A.  INrRODUCTION 

Whrn  developing  the  NPS  AUV  Simulator,  the  goal  was  to  incorporate  object  oriented 
features  into  the  data  structure.  The  auv  data  structure  inherits  its  characteristics  through 
the  use  of  “C*  language  pointers. 

The  auv  structure  contains  five  pointers  to  substructures.  The  Af/V_Po/ygo/ts  structure 
“poly”  contains  pointers  to  the  vehicle’s  polygons  encapsulated  in  the  NPGS  “OFF’ 
format  (Munson  1989).  The  Dynamic _Structure  “dyn”  contains  slots  required  to  compute 
polygon  (vertex)  transformations  from  accelerations.  The  Vehicle _Geometry  structure 
“geo”  contains  information  relative  to  a  specific  vehicle  such  as  the  mass  matrix. 
Information  in  the  mass  matrix  is  used  to  compute  the  vehicle  accelerations  fiom  the 
vehicle  forces.  Tne  Surfaces  structure  “surf’  contains  slots  depicting  the  state  of  the 
vehicle’s  external  control  surfaces;  rudders,  fins,  and  thrusters.  The  Coefficients  structure 
rontains  items  specific  to  the  submarine  such  as  hydrodynamic  coefficients  which 
determine,  among  other  things,  how  much  force  a  given  fin  deflection  will  generate,  or  how 
much  added  rnass  needs  to  be  applied  to  the  vehicle  during  accelerations.  Figure  S.  1  depicts 
the  essentials  of  the  auv  structure. 
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typedef  struct  { 

AUV_POLYGONS  poly; 

/  *  auv  objects  (polygons)  *! 

DYNAMIC.STRUCTURE  dyn; 

/*  forces,  torques,  accelerations  */ 

VEHICLE_GEOMETRY  geo; 

/*  vehicle  geometry  struct  */ 

COEFFICIENTS  coeff; 

!*  hydro  coeffidents  struct*/ 

SURFACES  surf; 

/*  fin  and  prop  deflections  •/ 

}  Submarine  *Sub_ptr, 

Figure  5.1  AUV  Data  Structure 
B.  AUV_POLYGONS  STRUCTURE 

The  current  NFS  Object  File  Format  docs  not  support  articulated  bodies. 
Transformation  may  only  be  applied  to  the  entire  object,  although  work  is  currently 
underway  to  add  this  capability.  The  AUV  has  fifteen  separate  moving  objects;  six 
propellers,  eight  fins,  and  the  hull.  The  submarine  can  be  built  from  the  seven  OBJECTS 
contained  in  the  AUV^Polygons  structure  depicted  in  Figure  5.2.  These  OBJECTS  arc 
parsed  into  the  structure  from  an  external  file  at  program  initialization. 


typedef  struct  { 

OBJECT  •hullobj;  /•  per  to  hull  polygons  •/ 
Object  •stcm_plancobj;  /•  ptr  to  stem  polygons  •/ 
OBJECT  •bow_planeobj;  /•  ptr  to  bow  polygons  •/ 
OBJECT  •rudobj;  /•  ptr  to  rudder  polygons  •/ 
OBJECT  •left_propobj;  I*  ptr  to  Lprop  polygons  •/ 
OBJECT  •n_propobj;  I*  ptr  to  r_prop  polygons  •/ 
OBJECT  •ihrusterobj;  /•  ptr  to  thruster  polygons  •/ 

)  AUV_POLYGONS; 


Figure  5J1  AUV  Polygons  Structure 


DYNAMICS  STRUCTURE 

The  dynamics  structure  contains  all  the  essential  items  for  computing  the  vehicle’s 
dynamics  and  kinematics,  which  is  more  thoroughly  covered  in  the  next  chapter.  However, 
a  brief  explanation  of  some  of  the  slots  in  Figure  5.3  will  be  covered  here. 


typedef  struct  { 

float  delta_time; 

/*  time  between  updates  */ 

float  forccs[6]; 

/*  forces  &  moments  *! 

float  mminvI6](6]; 

t*  inverse  mass  matrix  */ 

float  accelerations[6]; 

/*  udot,  vdot,  wdot  */ 

float  velocity(61; 

/*  u.v,w,p,q4-  */ 

float  positibn_change(6]; 

float  incremental_H_ma£rix; 

/*  for  body  axis  rotation  */ 

float  H_matrix(6][6]; 

/*  rotations  and  translations  */ 

float  T_matrix(6][6]; 

/*  for  Cockpit  View  */ 

float  pitch,  heading,  roll; 

/*  phi.  theta,  psi  *! 

1  DYNAMIC.STRUCTURE; 

Figure  5 J  Dynamic  Structure 


1.  Delta_tinie 

In  AUVl  and  AUV2,  delu_time  was  set  at  0.5,  regardless  of  the  system  frame 
rate.  To  portray  accurate  real  time  dynamics,  the  system  clock  must  be  used  AUV  in 
records  the  delta  time  just  before  each  swapbufTer  and  may  be  less  than  .05  (over  20  frames 
per  second).  The  value  is  utilized  when  integrating  the  accelerations  and  velocities.  The 
function  newjdeltajimeO  returns  the  time  (float  seconds)  since  the  function  was 
previously  called. 
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#include  “sys/times.h” 

#include  ‘“sys/param.h” 

float  ncw_delta_time() 

{  , 

struct  tms  spot_time;  /*  structure  from  times.h  *! 

static  float  oldtime; 
float  newtime; 

static  int  timestarted  =:  False; 
float  timc_diffcrencc; 

/*  convert  clock  ticks  to  seconds  using  HZ  */ 
newtime  =  (float)times(&spot_timc)/(float)HZ; 

if  (!  timestarted)  {  /*  first  reading  will  be  set  to  zero  */ 

oldtime  =  newtime; 
timestarted  =  True; 

) 

timc_difference  =  newtime-oldtime; 
oldtime  =  newtime; 
return  (time  difference); 

} 

Figure  5.4  Delta  Time  Routine 

2.  Forces 

This  slot  contains  an  array  of  the  forces  and  moments  produced  from  the  equations 
of  motions,  which  are  more  thoroughly  discussed  in  the  next  chapter.  The  force  vector  is 
multiplied  by  the  inverse  mass  matrix  to  obtain  the  accelerations. 

3.  Inverse  Mass  Matrix 

The  inverse  mass  matrix  is  determined  at  program  initialization  after  the  mass 
matrix  has  been  created.  The  mass  matrix  is  inverted  through  Gaussian  elimination 
techniques  in  AUV  III.  In  the  previous  AUV  Simulators,  the  inverse  mass  matrix  for  the 
SDV  was  formulated  using  a  Fortran  program  and  then  hard  coded  into  the  simulator  code. 
The  Gaussian  elimination  routine  is  shown  in  Figure  S.S. 
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IkferiiK  scan(var,  lower,  upp?r)  for(var=lower,  var<upper,  var++) 
inatrix_inveise2(IN_MArRIX,  INVERTED_MATR1X,  I5I2X) 
float  •IN.MATRDC; 
float  INVERTED„MATRIX[10000]; 
int  SIZE; 
i 

int  iiidex=0,  row=0,  col=0,  cuTrent_n>w=0;/ 
float  **TEMP,  factor,  row_factor, 

TEMP  =  (float**)«ialloc(SI2E  •  si2eof(float**));  /*  allocate  memofy  */ 

scaD(row,0,SIZE)  |  /*  create  temporary  augmented  matrix  */ 

TEMPfrow]  =  (float  •)  fflalloc(2  *  SIZE  *  sizeof(float)); 
scaa(col,0,  SIZE)  ( 

TEMP(rowHcol]  ■  IN.MATRDqrow  •  SIZE  +  col]; 

TEMP[row][col  +  SIZE]  =  0.0; 

I 

TEMPtrow][iow  +  SIZE]  =  1.0; 

I 

scan(index,0,  SIZE)  (  /*  set  &ctor  to  diagonal  component 

factor  ■  TEMP{carrent_row]larrrent_tow]; 

if  (factor  »  0)  (  /*  to  avoid  divisioo  by  a  factor  of  “0”  •/ 

scaiKtow,  0.  SIZE)  |  /*  find  row  that  doesn’t  have  zero  */ 

if  (TEMPltow][cunent_rowJ !»  0)  { 
scao(col,0,  (2*SIZE))  I 

TEMPtcurrwil_row][cd] +«  TEMP[row](col]; 

) 

factor  wTEMP(catTetu_row](cunent_tow]; 
break; 

) 

I 

I 

scao(col,0,  (2  •  SIZE))  |  /•  divide  current  row  by  factor  to  get  a  **1”  •/ 

T£MP(cnraeoi_tow](col]  ■  TEMP{catieiif_rowJ(col]  /  factor; 

) 

scaiKrow.O,  SIS)  (  /*  stdXract  (&aor  *  current  row)  from  each  row  */  . 

if  (row  !■  c«rrenl_row)  ( 
row_fBctor  ■  TEMP(row][cuncnt_tow]; 
acanfeot.  0.  (2  *  SIZE))  ( 

TEMP(rowJ(col]  -•  row_factor  •  ’TEMPtcanenr_n>w]Icol]; 

I 

)  , 

I 

cuneol.rowt  t;  , 

J  '  ' 

KaD(row.0,SlZB)  (  /*  create  matrix 

scan(col,0,  SIZE)  | 

INVERTED_MATRlX(row*SIZE -KoI]  -  TEMP(rbw](col+SIZE1; 

) 

I 

I 


Figure  Matrix  Inverse  Routine 
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4.  H-matrix 


The  homogeneous  transform  matrix  (H-matrix)  contains  the  information  required 
to  perform  polygon  transformations.  One  format  for  the  H-matrix  is  shown  in  figure  5.6 
which  results  from  a  yaw  followed  by  pitch,  then  a  roll.  The  transpose,  of  this  particular 
matrix  for  robotic  applications  is  found  in  (Fu  87) 


Figure  5.6  Homogeneous  Transform  Matrix 


By  loading  the  vehicle’s  H-matrix  onto  the  transformation  stack  prior  to  drawing 
the  vehicle,  proper  vehicle  orientation  results.  In  Chapter  6,  we  sec  several  uses  of  the  H- 
mauix  in  graphics  applications.  An  incremental  H-matrix  is  obtained  from  incremental 
rotations  and  translations  using  the  Graphics  Library  functions  calls  rotate()  and 
translcaei).  The  IRIS  4D  uses  a  right  hand  coordinate  system  with  X  axis  left  to  right,  Y 
axis  bottom  to  top,  and  negative  Z  axis  into  the  screen.  The  vehicle  coordinate  system  is 
shown  in  Figure  5.7.  To  utilize  OFF  objects  on  the  IRIS  with  minimum  confusion,  the 
vehicle  coordinate  system  should  be  initially  aligned  with  the  IRIS  world  coordinate 
system. 


Figure  5.7  Vehicle  Coordinate  System 


5.  T'lnatrix 

Is  is  often  useful  to  switch  to  a  “Cockpit”  or  “Camera”  view  while  operating 
vehicle.  The  function  transpose jnatrixQ  creates  a  “T-tnatrix”  from  the  H-matrix  b; 
transposing  the  upper  left  3x3  rotation  sub-matrix,  and  by  reversing  the  signs  of  th 
translations.  An  examination  of  the  H-macrix  reveals  that  such  a  transposition  produce 
rotations  opposite  that  of  vehicle  rotations.  When  flying  straight  and  level,  a  bank  to  th 
right  has  the  effect  of  tilting  the  horizon  to  the  left 


D.  VEHICLE  GEOMETRY  STRUCTURE 


The  Vehicle  Geometry  structure  contains  information  that  is  peculiar  to  that  type  of 
vehicle.  For  example,  center  of  buoyancy  information  is  used  for  ships  whereas  wingspan 
area  may  be  used  for  aircraft.  Slots  within  this  structure  (Figure  5.8)  arc  amplified  in  the 
following  paragraphs. 


typedef  struct  { 

float  mass; 

/*  weight  /  gravity  */ 

float  weight; 

/*  to  compute  mass  V 

float  buoyancy; 

/*  will  equal  gravity  */ 

float  length; 

/*  dimensions  in  feet  */ 

float  slice[3](9]; 

/*  length,  width,  height  xsection  */ 

float  AO; 

!*  prop  area  */ 

float  xg,  yg,  zg; 

/•  distance  eg  from  rotation  axis  •/ 

float  xb,  yb,  zb; 

/*  distance  cb  firom  rotation  axis  */ 

float  ix,  iy,  iz; 

/*  symmetric  moments  of  inertia  */ 

float  ixy,  ixz,  iyz; 

/•  asynunetric  moments  of  inertia  */ 

float  nun(61[6]; 

/•  mass  matrix  •/ 

)  VEHICLE_GEOMETRY; 

Figure  5Ji  Geometry  Structure 


1.  Mass  Matrix 

The  mass  matrix  is  a  fimetion  of  mass,  added  mass  coefficients,  center  of  gravity  (xg, 
yg,  zg),  moments  of  inertia  (ix,  iy,  iz),  products  of  inertia  (ixy,  ixz,  iyz),  water  densityfrho), , 
and  vehicle  length.  At  program  initiation,  the  added  mass  coerficients  are  read  into  the 
added  mass  coefficient  array  (see  Coefficient  Struemre  below).  Using  these  coefficients 
and  ihe  other  aforementioned  parameters,  the  mass  matrix  is  created  by  the  function 
compute _mass_matrix()  using  the  mass  matrix  equations  outlined  in.(Boncal  1987).  The 
mass  matrix  was  “hard  coded”  into  AUV2  using  the  SDV  parameters.  In  AUV  III,  the 
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parameters  are  read  in  at  program  initialization  so  the  simulator  can  be  run  with  any 
geometry.  In  addition,  the  AUV  HI  parameters  have  been  modified  to  reflect  the 
submarines  symmetry  and  size. 

2.  Other  AUV  Geometry  Considerations 

The  propeller  cross-sectional  area,  AO,  is  used  in  the  AUV’s  equations  of  motion. 
Since  the  AUV  is  considered  a  rigid  body,  the  various  forces  can  be  represented  as  three 
disciieet  forces  along  the  vehicle  axes,  and  the  moments  as  three  discreet  moments  around 
these  axes.  These  equations  are  discussed  in  Chapter  6. 

In  AUV  ni,  the  buoyancy  and  weight  are  of  equal  magnitude.  The  greater  the  distance 
between  the  center  of  gravity  and  center  of  buoyancy,  more  stable  but  less  maneuverable, 
is  the  submarine  Using  dynamic  constraints  as  discussed  in  (Barzel,  Barr  1988),  one  may 
implement  constraints  by  introducing  forces  into  the  model  to  simulate  acmal  vehicle 
behavior.  In  AUV  IE,  by  artificially  increasing  the  weight  as  the  vehicle  broaches  the 
surface,  the  equations  of  motion  generate  a  pitch  down  motion  followed  by  a  vehicle 
levelling  out,  preventing  a  “flying”  AUV. 

The  “slice”  matrix  is  used  in  the  dynamics  package  to  help  compute  cross  flow  drag. 
Nine  cross  sectional  measurements  were  taken  of  the  AUV  for  the  matrix.  Cross  flow  drag 
■is  integrated  over  the  length  of  the  vehicle  using  the  trapezoidal  rule,  with  respect  to  height 
or  width. 

E.  COEFnCIENTS  STRUCTURE 

The  Coefficients  structure  is  shown  in  Figure  5.9. 
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typedef  stmet  { 

/*  contains  hydro  coefficients  */ 

float  surge(6][6]; 

/♦  vehicle  x  axis  movement  */ 

float  sway [6]  [6]; 

!*  vehicle  y  axis  movement  */ 

float  heave[6][6]; 

/*  vehicle  z  axis  movement  */ 

float  roU[6][6]; 

/*  angular  abou^  z  axis  *f 

float  pitch[6][6]; 

/*  angular  about  x  axis  */ 

float  yaw[6][6]; 

/*  angular  about  y  axis  */ 

float  added_mass[6][6];  /*  added  mass  effects  during  acceleration  */ 
float  fin_sufgc'6][4];  /*  fin  movement  &  vehicle  movement  */ 

float  fin[6][4]; 

/*  fin  only  */ 

char  *surge_variables[6][6]; 
char  *sway_variables[6][6]; 
char  *heave_variables[6][6]; 

char  *roll_variables[6][6]; 
char  ♦pitch_variables[6](6]; 
char  *yaw_variables(6][6]; 

/*  required  for  file  regenerations  ♦/ 

char  *added_mass_variables(6][6]; 

char  *fin_surge_variables(6]t4]; 
char  *fin_variables[6][4]; 

)  COEFFICIENTS,  •CO.PTR; 

■ 

Figure  5.9  Coefficient  Structure 


While  accurate  hydrocoefficients  are  often  obtained  after  exhaustive  tow  tank 
experiments,  the  SDV  coefficients  were  obtained  through  geonmstrical  analysis  (Smith 
1978).  In  AUV  HI,  the  coefficients  were  modified  to  exclude  the  effects  of  the  third 
propeller  and  large  skeg  on  the  SDV:  Again,  in  AUV2,  the  coefficknts  were  “hard  coded” 
and  included  only  those  coefficients  thought  to  be  affecting  the  AUV.  In  AUV  III,  a  full  set 
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of  coefficients  are  included  enabling  configuration  changes  (size,  control  surfaces, 
propellers,  etc.)  to  be  immediately  run  on  the  simulator. 

Coefficient  files  can  be  loaded  into  the  simulator,  modified  on-line,  tested,  and  saved 
for  reuse.  While  the  added  mass  coefficients  were  utilized  in  the  development  of  the  mass 
matrix,  die  remaining  coefficients  are  utilized  in  the  equations  of  motion.  Since  the  AUV 
is  somewhat  symmetrical,  most  of  the  off-diagonal  terms  should  be  approximately  zero. 
Figure  5.10  shows  the  on-line  panel  for  modifying  pitch  coefficients.  The  coefficient  can 
be  decoded  using  the  following: 

X  =  Surge 
Y  =  Sway 
Z  =  Heave 
K  =  Roll 
Ms  Pitch 
N  =  Yaw 

For  example,  MUV  is  the  coefficient  that  deteimines  how  much  pitch  force  is  induced 
when  the  vehicle  undergoes  a  surge  with  a  sway.  The  coefficients  should  be  modified  after 
each  ill-water  testing  of  the  vehicle. 

The  coefficient  files  are  similar  to  ordinary  “C”  language  header  ^es  and,  in  fact,  may 
be  hard  coded  at  any  time.  The  data  structure  records  the  name  of  the  coefficient  so  that  the 
file  may  be  properly  restructured  in  this  “C”  format  when  saving  any  changes. 

F.  SURFACES  STRUCTURE 

The  Surfaces  structure  contains  the  status  of  all  controls  surfaces  of  the  vehicle.  The 
fin  deflections  and  thruster  ipms  are  uiputs  to  the  equations  of  motion.  While  the  AUV  has 
slots  for  eight  fin  deflections,  enabling  independent  fin  surface  control,  the  current 
equations  do  not  support  this  mode.  The  bow  and  stem  control  surfaces  are  coupled  as  are 


the  left  and  right  main  thnister.  The  hovering  thrusters  are  not  yet  modeled  in  the  equations. 
Figure  5.11  depirts  the  Surfaces  stmcture. 

typedef  stmct  { 

float  deflect[8];  /*  eight  control  surfaces  */ 

float  ipm[6];  /*  two  mains  and  six  thrusters  */ 

float  prop_disp[6];  /*  rotations  in  one  frame  */ 

)  SURFACES; 


Figure  5.11  Control  Surfaces  Structure 


VI.  AUV  DYNAMICS 


A.  INTRODUCTION 

1.  Dynamics,  Animacion,  and  Simulation 

With  the  advent  of  lo^v  ost,  powerful  graphic  workstations,  animating  rigid  body 
motion  through  dynamic  equations  of  motion  is  becoming  an  attractive  alternative  to 
traditional  graphics  animation  techniques  such  as  inverse  kinematics,  keyframing,  and  goal 
directed  subsystems  (Sturman  1987).  While  the  teim  “simulation”  instead  of  “animation” 
suggests  a  shift  of  control  from  the  animator  to  the  underlying  physics,  tb*-  need  not  be  the 
case.  The  DY!^AMO  system  at  Cornell  University  allows  the  animator  to  maintain  control 
of  linked  figures  in  the  dynamic  simulator  through  use  of  kinematic  constraints  and 
predefined  behavior  functions  (Isaacs  1987).  For  the  animator  or  “simulator”,  Sturman 
suggests  that  dynamics  may  be  the  best  way  to  achieve  realistic  motion .  Jane  Wilhelms 
(Wilhelms  1987)  also  cites  a  number  of  reasons  to  use  dynamics. 

a.  Restrict  motions  to  those  which  are  realistic. 

b.  Portrays  complex  motion  with  minimal  user  input. 

c.  Dyhamic  constraints  can  be  automatically  imposed. 

d.  Move  complex  bodies  in  a  natural  way. 

2.  How  to  Employ  Dynamics 

Wilhelms  itemizes  the  steps  required  to  derive  object  motion  from  dynamics. 
Though  general  in  nature,  they  reflect  the  procedure  used  in  Gomell’s  DYNAMO  system 
as  well  as  the  NPS  AUV  Simulator.  They  are: 
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a.  Build  dynamic  equations  of  motion 

b.  Solve  equations  for  forces  and  accelerations. 

c.  Detcrmire  velocides  and  positions  through  integration. 

d.  Update  the  object’s  state. 

Dynamic  constraint  checks  should  be  accomplished  after  step  “c”.  For  instance, 
one  constraint  may  be  that  the  AUV  never  “fly”  out  of  the  water.  Rather  than  using 
kinemadc  constraints,  i.e.,  no  transladons  above  zero  aldmde,  we  would  shift  the  center  of 
buoyancy  towards  the  aft  of  the  vehicle,  and  then  resolve  for  the  eqtiadons  of  modon.  The 
equadons  would  recognize  the  lower  biioyancy  moment,  and  the  resultant  greater  weight 
moment  would  cause  the  vehicle  to  pitch  down  into  a  dive.  If  the  bow  and  stem  planes  were 
not  readjusted,  there  would  be  a  porpoising  eflect,  and  the  vehicle  would  remain 
constrained  in  its  environment 

B.  AUV  EQUATIONS  OF  MOTION 

The  original  sets  of  equations  of  modon  for  the  AUV  were  adapted  from  the  submarine 
equadons  of  modon  for  the  Swimmer’s  Delivery  Vehicle  (Boncal  1987).  Modificadons  to 
the  equadons  included  (1)  integral  formulation  of  viscous  crossflow  forces  and  moments; 
(2)  decoupling  of  the  bow  and  stem  planes  ( 3)  decoupling  of  the  left  and  right  bow  planes. 
In  AUV  m,  the  viscous  cross  flow  formula  was  renrxxlined  and  the  third  (off  axis)  propeller 
was  removed, 

1.  Viscous  Crossflow  Forces 

In  order  to  compute  the  viscous  flow  components,  nine  cross-slice  measurements 
were  taken  of  the  AUV.  Crossflow  cotnponents  were  then  calculated  by  integradng  the 
calculations  over  the  length  of  the  vehicle  as  shown  in  Figure  6.1. 
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#definc  x9  auv->geo.slice(OJ  /*  nine  auv  height,  width  measurements  */ 
#define  br  auv->geo.slice{l) 

#define  hh  auv->geo.slice{2] 

#define  num_pts  9 

#define  swayteim  (W  +  x9[k]  *  RR) 

#define  hcaveterm  (WW  -  x9(k]  *  QQ) 

computc_drag_forcc(auv) 

Sub_ptr  auv; 

{ 

intk; 

f  loat  cyflow  .czflow,  ucflnum_pts],  vcchl[numj)ts).  vcch2[num_pts] 
trapczoidalO.vecv  1  [num_ptsj,vecv2[num_pts]; 

for  (k=0;  k<num_pts;  k++)  { 

ucfTk)  =  fsqrt((swaytcrm  *  swayterm)  +  (heaveterm  *  heaveteim)); 
if(ucf[k]  >=  l.e-10)  { 

cyflow  =  f_cdy  *  hh[k]  *  swayterm  *  swayterm; 
czflow  =  f_cdz  *  brfk)  •  heaveterm  *  heaveterm; 
vechlfk]  =  (czflow  +  cyflow)  *  swayterm  /  ueftkj; 
veev  1  [k]  =  (czflow  +  c)d)ow)  •  heaveterm  /  uc^k); 
vcch2[ki  =  vcchl(kl  *  x9(kj; 
vecv2[ki  =  vccvl(kj  •  x9ik); 

)  else  { 

f_heave  =  f_pitch  =  f_sway  »  f _yaw  =  0; 
return; 

) 

) 

f_hcavc  *  (trapczoidal(num_pts,  vccvl,  x9)*f_rho/2.)*  (-1); 
f_pitch  » (trapczoidal(num_pfs,  vccv2,  x9)*f_rho^.); 
f_sway  ■  (trapczoidal(num_pts,  vcchl,  x9)*f_rho/2.)*  (-1); 
f_yaw  a  (tr3pczoi^(num_pts,  vcch2,  x9)*f_rho/2.)*  (- 1 ); 

)  I*  end  compute  drag  force  */ 

float  trapezoidal(points.  veLarray,  distance) 
int  points;  float  vel_arTayn  .  distanced; 

float  answer,  int  ij  Jt; 
j  ■  points;  answer  ■  0.0; 
forfjaO;  i++)  | 

answer  +■  (25  •  ((vcl_array(i]4-veLaiTay(i+ll)  • 

(distance(i-f  1)  •  disunce(i)))); 

) 

return  (answer); 

) 


Figure  6.1  Viscotis  Drag  Force  and  Moments 


2.  Equations  Format 

The  Submarine  equations  have  a  standard  format  as  shown  in  (Boncal  1987). 
Figure  6.2  is  the  header  file  used  to  maintain  the  format  while  using  the  AUV  data  structure. 
Figures  6.3  through  6.9  are  the  current  AUV  equations. 


#define  f_L 
#deiineUU 
#define W 
#dcfine  WW 
#define  PP 
#defineQQ 
«de<ineRR 
#define  ptu 
#definetheu 
idefinepsi 
#define  f  rtio 


auv->geo.length 

auv->dyn.vel[0] 

auv->dyn.vel(l] 

auv->dyn.vcl[2] 

auv->dyn.vcl(31 

ajv->dyn.vcl(41 

auv->dyn.vel(51 

auv->roU/57.3 

auv->pitch/57.3 

auv->heading/S7.3 

l.94/*auv->  rtw 


density  of  water 


/*  iKxi-dimensionalized  coeffidents  for  use  with  equations  of  motion  */ 
#define  ndc5(floatXf_rt»/2  •  f_L  *  f_L  *  f_L  *  f_L  *  f_L) 
idefine  ndc4(floatXf_rho/2  *  f_L  •  f.L  *  f  L  •  f  L) 

#definc  ndc3(floatXf_rho/2  •  f.L  •  f_L  •  f.L) 

#define  ndc2(floatXf_rtKV2  •  f.L  *  f_L) 

#dcfine  f_cdy  (float)1 .0  /•  drag  factors  V 

#define  f_cdz  (fioat)l.O 

#dcfinc  f_nu  (fioat).00847  /•auv->  nu*  / 

•define  f_re  (floaiXUU  •  f_L  /  fj.nu) 

•define  f_cu(.008  •  f.ipm  /  UU)/*  vice  .012  •/ 

•define  f.al.OOS  •  f_L  •  LL/aO 

•define  f_a008  •  f_L  •  fJL  •  f_eu  •  fabs(f_eta)  /  aO 

•define  f_cd0(floaiX.00085  +  (1.296e-I7)  •  (f_re  -  1.2e7)  •  (f_re  -  I.2e7)) 

•define  fx_prop(f_cdO  •  (f_eu  •  fabs(f.eu)  - 1.0)) 

•defirtc  &i_prop0 
•define  flt_prop0 

typedef  struct  {  /*  structure  used  to  decompose  equations  */ 

float  Newton_Eulert6]: 
float  hydro_angular_angular(61; 
float  hydro.Unear_aitguiar(6);. 
float  hydro  JinearJinear{6): 
float  drag(6]: 
float  hydro_static(6]: 

)  1total_Forces.  •TFoice; 


Figure  6.2  Equations  of  Motion  Header 
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conipute_si  «e_forc{;<’"aY4; 

Sub_ptr  auv; 

T^nrr^  f; 

( 

»Ti£  facinrl,  tsr;  jf<..  acce!eration_factor; 

accsls.vuor._iai:u>.’  =  fx_prop  *  UU  •  UU  *  f_L  •  1 L  •  f_rtio  /  2.0; 
f->N.:  wton_Euler(X]  = 

f.  n  jj'. '  O’  V  *  -RP.  'h’Y  •  QQ  /*  iner  ■  .<i  t^Iec;  “/ 

» 1  xg  *  ( "JQ  •  QQ  %  KA  *  fLR)  /*  center  c  1  m^s  f  -kcts  */ 

-  f’_j  g  *  ?P  •  QQ 
j  -  x_zg  *  PP  *  RR); 

I  i  >hydn)_angular_anp»;’ar(X]  f  icw  d-  c  '.o  •/ 

;dc4  *  (xpp  *  PP  *  PP  +  /*  roU  V 
xqq  *  QQ  *  QQ  *  /*  r  i- *'  */ 
xpr  *  PP  *  RR  +  /•  yaw  &  wi;  */ 
xir"^RR*RR);/*yaw*/ 

f->hydroJincar_a-!g’jia  tXl  -  /*  suige  force  due  to  */ 
ndc3  •  (xwq  •  WV,'  *  <;'0  +  hr  .ve  &  pitch  •/ 
xvp  •  W  •  PP  +  ./*  V  .  y  &  rot:  •  / 
xvr  *  W  •  RR );  /*  :  /ay  &  yaw  •/ 

f->h'"ljr<_iir.earJire«fX]  =  /*  surge  force  due  to  •/ 
iidc2  •  (xw  W  •  W  + /•  sway  •/ 
xww  •  WW  *  W^V  +  /•  heave  */ 
xvdr  •  UL  •  W  •  f_dr  +  /*  rudder  &  sway  &  surge  */ 
xwds  *  UU  •  WW  •  f_ds  +  /•  stem  plane  &  surge  &  heave  */ 
xwdb  *  UU  ■*  WW  •  f_db  + 1*  bow  plane  &  surge  &  heave  */ 
xqds  *  UU  •  QQ  •  f_ds  +  f*  stem  plane  &  surge  &  pitch  •/ 
xqdb  •  UU  •  QQ  •  f_db  + 1*  bow  plane  &  surge  &  heave  •/ 
xdsds  •  UU  ‘UU^f  ds*f  d-s  +  i*  stem  plarre  &  surge  */  , 
xdbdb  •  UU  •  LU  •  f_db  •  f_db  +1/*  bow  plarrc  &  surge  •/ 
xdrxlr  *  UU  •  IfU  •  f_dr  •  f_dr  +  k  rudder  &  surge  */ 
acceleration_factor);  r  rpm  &  surge  */ 


f->drag(X]  a  0.0;  /*  cross  flow  drajg  */ 

f->hydro_static(X1 »  /•  buoyancy,  weight,  pitch  angle  •/ 
(-f_ weight  +  boy)  •  SIN_THETA; 


Figure  6  J  Surgf  Equation  of  Motion 


compute_sway_force(auv,f) 

Sub_ptr  auv; 

TForce  f; 

{ 

f->Ncwton_Euler{Y]  =  !*  sway  force  due  to  */ 
f_mass  *  (WW  *  PP-  UU  •  RR/*  inertial  effects  */ 

-  f_xg  *  PP  *  QQ  /*  center  of  mass  effects  */ 

+  f_yg  *  (RR  ^  RR  +  PP  *  PP) 

-f-zg*QQ*RR); 

f->hydro_angular_angular( Y]  =  t*  sway  force  due  to  */ 
ndc4  *  (ypq  *  PP  •  (JQ  +  /*  roll  &  pitch  */ 
yqr  *  QQ  *  RR);  /*  pitch  &  yaw  */ 

f->hydro_Iincar_angular(Y]  =  I*  sway  force  due  to  *l 

ndc3  *  (f_yp  *  UU  *  PP  +  /•  surge  &  roll  */ 

f_yr  *  UU  •  RR  +  /♦  surge  &  yaw  •/ 

yvq  •  W  ♦  QQ  +  /•  sway  &  pitch  */ 

ywp  *  WW  •  PP +  /•  heave  &  roU  V 

ywr  *  WW  •  RR); /*  heave  &  yaw  */ 

f->hydro_lincar_Iinear(Y]  =  /*  sway  force  due  to  */ 
ndc2  •  (f_yv  •  UU  *  W  +  /•  surge  &  sway  */ 
yvw  ♦  W  •  WW  +  f*  sway  &  heave  */ 
ydr  *  UU  •  UU  •  f_dr);  /•  rudder  &  surge  •/ 


f->drag(Y]  = 

f_sway;  i*  viscous  left  &  right  cross  flow  drag  •/ 

f->hydro_staric(Y]  ■  /*  wieght,  buoyancy,  pitch  angle,  roll  angle  •/ 
(Lweight-boy)  •  COS.THETA  •  SIN_PHI; 

) 


Figure  6.4  Sway  Equation  of  Motion 
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computc_heave_force(auv^ 

Sub_ptr  auv; 

TForcc  f; 

{ 

f->Ncwton_EulcT(Z]  =  /*  heave  force  due  to  */ 
f.mass  *  (UU  •  QQ  -  W  *  PP  /*  inertial  effects  */ 

-  f_xg  *  PP  ♦  RR  /*  center  of  mass  effects  */ 

-  Ug  *  QQ  •  RR 

+  f_zg*(PP*PP  +  QQ*QQ)); 

f->hydro_angular_angular[Z]  =  /*  heave  force  due  to  */ 
ndc4  *  (zpp  *  PP  PP  +  /*  roll  */ 
zpr  *  PP  *  RR +/*  roll  &  yaw  */ 
ztr  *  RR  *  RR);  /*  yaw  */ 

f->hydro_linear_angulartZ]  =  /*  heave  force  due  to  */ 
ndc3  *  (f_2q  •  UU  *  QQ  +  /*  surge  &  pitch  *f 
2vp*  W  •  PP  +  /*  sway &roll  •/ 

2vr  •  W  •  RR);  /*  sway  &  yaw  */ 

f->hydro_linear_lincar(Z]  =  /•  heave  force  due  to  •/= 
ndc2  *  (f_zw  •  UU  •  WW  +  /*  surge  &  heave  */ 
zw  •  W  *  W  +  /*  sway  */ 
zds  *  UU  *  UU  *  f_ds  +  /*  stem  plane  &  surge  */ 
zdb  *  UU  •  UU  *  fLdb);  /*  bow  plane  &  surge  •/ 

f->drag[Z]* 

f_heave;  /*  viscous  up/down  cross  flow  drag  */ 

f->hydro_stadc(Z]  =  /*  buoyancy,  weight,  pitch,  roll  angle*/ 
(f_weight-boy)  •  CX)S_THETA*COS_PHI; 

}  /*  end  heave  */ 


Figure  6,5  Heave  Equation  of  Motion 


compute_roll_moment(auv,f) 

Sub_ptr  auv; 

TForce  f, 

{ 

f->Newton_Euler(K]  = 

(fjy  -  f_iz)  *  QQ  *  RR  -  /*  moment  of  inerda  effects  */ 
f_ixy  *  PP  *  RR  +  /*  pitxlua  of  ineitia  effects  */ 
f_ixz  *  PP  *  QQ  + 
f  Jyz  *  (QQ  *  QQ  -  RR  *  RR) 

+  f_mass  *  (f_yg  *  (UU  •  QQ  -  W  *  PP)  -  /*  center  of  mass  effects  */ 
f_zg  *  WW  *  PP  +  UU  ♦  RR): 

f->hydro_angular_angular(K]  =  /*  roU  moment  due  to  */ 
ndc5  (kpq  •  PP  *  (JQ  +  /*  roll  &  pitch  */ 
kqr  *  <5Q  *  RR);  /*  pitch  &  yaw  */ 

f->hydn)_linear_angulailK]  =  /*  roll  moment  due  to  •/ 

ndc4  *  (f_kp  •  UU  *  PP  + /•  suigc  &  roU  •/ 

f_kr  *  UU  *  RR  +  /*  surge  &  yaw  */ 

kvq  *  W  •  (2Q +  /•  sway  &  pitch  */ 

kwp  •  WW  *  PP+/*  heave  &  roU  */ 

kwr  ♦  WW  •  RR  );  /•  heave  &  yaw  •/ 

f->hydTO_linear_linearf  K]  =  /*  roll  moment  due  to  */ 
ndc3  *  (f_kv  *  UU  *  W  +  /*  surge  &'sway  */ 
kvw  •  W  *  WW  +  /*  sway  &  heave  */ 
fk  jxop  •  UU  *  UU);  /•  surge  &  prop  factor  V 

f->drag[K]  =  0.0;  /*  roll  drag  effects  •/ 

f->hydro_static(K]  =  /*  pitch,  roll,  buoyancy/ weight  */ 

(f_yg  *  f_wcight  -  f_yb  *  boy)  •  COSJTHETA  *  COS.PHI  + 

(fjtb  *  boy  -  f_2g  •  f_weight)  *  Sirf_PHI; 

)/*cndroU*/ 


Figure  6.6  Roll  Equation  of  Motion 
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compute  _pitch_moment(auv,f) 

Sub_ptr  auv; 

TForce  f; 

I 

f->Newton_Euler(M]  =  /*  pitch  moment  due  to  */ 

(f_iz  -  f_ix)  *  PP  *  RR  +  /*  moment  of  inertia  */ 
fjxy  *  QQ  *  RR  -  /•  product  of  inertia  *! 
fjyz  *  PP  *  QQ  + 
fJxz*(RR*RR  +  PP*PP) 

+  f_mass  *  (f_xg  *  (W  *  PP  +  UU  ♦  QQ)  +  /*  center  of  mass  effects  */ 
f_zg  *  (W  *  RR  -  WW  *  QQ)): 

f->hydro_angular_angularlM]  =  /*  pitch  moment  due  to  */ 
ndc5  *  (mpp  *  PP  •  PP +,/*  roU  */ 
mpr  •  PP  *  RR  +  /•  roll  &  yaw  •/ 
mrr  *  RR  ■*  RR);  /*  yaw  */ 

f->hydro_linear_angulartM]  =  /*  pitch  moment  due  to  •/ 
ndc4  •  (f_mq  *  UU  *  QQ  +  /*  surge  &  pitch  •/ 
mvp  •  W  •  H*  +  /*  sway  &  roll  */ 
mvr  *  W  *  RR ):  /*  sway  &  yaw  */ 

f->hydroJincar_lineartM]  =  /*  pitch  moment  due  to  •/ 
ndc3  *  (f_mw  *  UU  ♦  WW  +  /*  surge  &  heave  */ 
mw  •  W  •  W  +  /*  sway  */ 
mds  *  UU  *  UU  *  f_ds  + 1*  stem  plane  &  surge  *! 
mdb  •  UU  •  UU  •  f_db); /•  bow  plane  &  surge  •/ 

f->drag(Ml  = 

fjjitch;  I*  up/down  viscous  drag  momerit  */ 

f->hydro_static(M]  =  /*  buoyancy,  weight,  pitch,  roll*/ 

(f_xb  *  boy  -  f_xg  *  f.weight)  *  COS.THETA  •  COS.PHI 
+  ((f_zg  -  f_zb)  *  (f_weight-boy))  •  SIN^THETA; 

)  f*  end  pitch  •/ 

Figure  6.7  Pitch  Equation  of  Motion 
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compute_yaw_moment(auv.f) 

Sub_ptr  auv; 

TForce  f; 

{ 

f->Newton_Euler(N]  =  /*  yaw  moment  due  to  */ 

(f_ix  -  fjy)  *  *  QQ  /*  moment  of  inertia  */ 

+  fjxy  *  (PP  *  PP  -  QQ  *  QQ)  I*  pnxJucts  of  inertia  */ 

-  f_ix2  *  QQ  *  RR 
+  fjyz  *  PP  *  RR 

+  f_mass  "■  (f_xg  *  (UU  *  RR  +  WW  *  PP)  /*  cenert  of  mass  effects  */ 

-  f_yg  *  (WW  •  QQ  -  W  *  RR)); 

f->hydio_angular_angular(N]  =  /*  yaw  moment  due  to  */ 
ndc5  *  (npq  *  PP  *  QQ  +  /*  roll  &  pitch  */ 
nqr  *  QQ  ♦  RR);  /•  pitch  &  yaw  */ 

f->hydrD_linear_angular(N]  =  /*  yaw  moment  due  to  */ 

ndc4  •  (f_np  •  UU  *  H*  +  /*  surge  &  roU  */ 

f_nr  *  UU  *  RR  +  /*  surge  &  yaw  •/ 

nvq  •  W  *  QQ  +  /•  sway  &  pitch  */ 

nwp  *  WW  *  H*  +  /•  heave  &  roll  */ 

nwr  *  WW  *  RR);  /•  heave  &  yaw  */ 

f->hydto_lincar_lincar{N]  =  /*  yaw  moment  due  to  V 
ndc3  *  (f_nv  *  UU  *  W  +  /*  surge  &  sway  */ 
nvw  *  W  *  WW  +  /*  sway  &  heave  */ 
ndr  *  UU  *  UU  *  f_dr +/*  .  surge  &  rudder  */ 
fn_prap  •  UU  •  UU);  /*  surge  &  prop  */ 

f->drag[N] « 

•f_yaw; /•  lefVtight  drag  moment  */ 

f">hydro_static(N] »  /•  buoyancy,  weight,  pitch,  roll  */ 

(f_xg  *  f.weight  -  f_xb  •  boy)  •  COS.THETA  *  SIN.PHI 
+  (f-yg  •  f_weight  -  f_yb  *  boy)  *  SIN.THETA; 

}  /•  end  yaw  */ 

Figure  6.8  Yaw  Equation  of  Motion 
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C.  SOLVING  FOR  FORCES,  TORQUES,  &  ACCELERATIONS 


The  six  equations  (Figures  6.3  -  6.8)  are  subdivided  into  six  sub-equations.  The  first, 
“Newton-Euler”,  are  inertial  forces  or  moments  resulting  from  velocities,  moments  and 
products  of  inertia,  as  well  as  force  created  since  the  center  of  mass  is  not  at  the  cente:  of 
the  AUV’s  coordinate  system  (center  of  buoyancy). 

The  second  set  “an^lar-angular”  are  forces  generated  due  to  rotational  velocities 
around  the  other  two  axes.  The  third  set  “angular-linear”  are  forces  generated  due  to  a 
combination  of  an  angular  velocity  and  a  linear  velocity.  The  fourth  sub-equation  solves  for 
the  force  created  when  two  linear  velocities  are  combined. 

The  fifth  sub-equation  shows  the  force  generated  due  to  cross-flow  drag  as  discussed 
earlier  in  the  chapter.  The  sixth  set  are  forces  due  to  hydrostatic  effects  caused  by  the  offset 
of  the  center  of  buoyancy  from  the  center  of  gravity. 

One  force  or  torque  is  generated  for  each  degree  of  freedom  and  placed  into  a  six 
clement  force  vector.  The  vector  is  post-multiplied  by  the  inverse  mass  matrix  to  produce 
a  six  clement  acceleration  vector  (Figure  6.9). 


/*  multiply  force  vector  b’-'  inverse  mass  matrix  to  get  acceleration  vector  */ 
computc_accclcrations''<i  dv) 

Sub_ptr  auv; 

{ 

intjdc; 

for  (j=0;  j<6;  j++)  { 
for  (k^;  k<6;  k++){ 

auv->dyn.acclj]  +=  auv->dyn.mminv(j][k]  •  auv->dyn.forces(k]; 

) 

} 

} 


Figure  6.9  Solving  for  Accelerations 
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D.  SOLVING  FOR  VELOCITIES  &  POSITION  CHANGES 


The  are  many  integration  methods  available  for  deriving  positional  information  from 
the  acceleration  vector.  One  of  the  most  accurate  but  more  complex  and  slower  is  the 
Rmgs-Kima  Method  (Wilhelms  1987).  On  the  other  end  of  the  spectrum  is  the  Euler 
Method  which  is  fast,  but  inaccurate,  especially  for  higher  delta  times.  This  is  illustrated  in 
Figure  6.10. 


The  Euler  method  samples  the  velocity  at  a  given  point,  assumes  a  constant 

velocity,  and  calculates  a  future  position  according  to  the  equation  below.  The  calculation 

pi  ss  p0  + vO-  5f 

works  well  for  very  small  delta  times,  but  can  be  erroneous  at  higher  intervals.  During  non- 
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graphical  AUV  dynamic  calculations,  vhere  real  time  is  not  an  issue,  the  delta  times  can 
be  very  small  indeed.  Preliminary  AUV  dynamic  tests  used  delta  times  of  1  msec.  AUV 
SIM2  needed  to  approximate  the  graphical  frame  rate  to  get  realistic  motions  and  used  a 
delta  time  of  0.5  seconds  in  conjunction  with  the  Euler  Method.  AUV  SIM  HI  uses  the 
system  time  to  get  an  accurate  delta  time,  usually  between  0.1  and  0.15  seconds.  It  was 
felt  that  even  this  interval  was  too  great  for  the  Euler  Method,  so  the  Modified  Euler  Method 
(Spiegal  1988)  was  adopted.  In  the  modified  method,  a  predicted  average  velocity,  rather 
than  an  initial  velocity  is  used.  The  average  velocity  is  calculated  based  on  the  acceleration 
at  sample  time,  and  the  equation  now  becomes: 

pi  =  p0  +  v0-5t+ (aO- (5r)^)/2 

The  routine  for  calculating  the  new  velocities  and  position  changes  is  depicted  in 
Figure  6.11. 


compute_velocities_and_positions(auv) 

Sub_ptr  auv; 

{ 

int  i; 

static  int  dtr  =  573;  /*  degree  to  radian  conversion  (SGI  uses  lOths)  */ 
for  (i=0;  i<6;  i++)  { 

auv->dyn.vel[i]  +=  auv->dyn.delta_t  *  auv->dyn.acc[i]; 

auv->dyn.pos_change(i]  = 

((auv'>dyn.delta_t  *  auv->dyn.vcl[i])  + 

(auv->dyn.delta_t  ♦  auv->dyn.delta_t  • 
auvT>dyn.acc[i}  /  2.0)) ; 
if  (i>2)  auv->dyn.pos_change[i]  *=  dtr„ 

} 

) 


Figure  6.11  Velocity  and  Position  Change  Routine 


E.  UPDATING  THE  AUV’S  STATE 


1.  Create  the  increinental_H_inatrix 

The  incremental  positional  changes  are  relative  to  the  vehicle  coordinate  system, 
and  must  be  converted  to  the  world  coordinate  system.  By  loading  the  incremental  changes 
into  an  incremental  homogeneous  transform  matrix,  we  can  take  advantage  of  the  IRIS  4D 
transformation  stack  and  the  graphics  library  mdtmatrix()  function  to  make  the  necessary 
transformations.  The  routine  in  Figure  6.12  creates  the  incremental  H-matiix,  again  taking 
advantage  of  the  transformation  stack  and  the  graphics  library  functions  rotateQ  and 
getmatrix(). 

void  get_incremental_H._rr4atrix_from_position_changes(auv) 

Sub_ptr  auv; 

{ 

pushmatrixQ; 
loadunitO; 

rotate(-(Anglc)auv-xlyn.pos_change[5],  ‘y’);  /*  yaw  */ 
iotate(  (Anglc)auv->dyn.pos_changc[4],  ‘x’);  /*  pitch  */ 
rotatc(-(Angle)auv->dyn.pos_change(3],  ‘z’);  /*  roll  */ 
getmaitrix(auv->dyn.incremental_H_matrix); 
popmatrixO; 

} 


Figure  6.12  Transforming  to  World  Coordinates 


a.  Rotation  Order  Matters 

In  Figure  6.12,  notice  that  the  yaw  is  applied  first,  and  the  roll  is  applied  last 
Euler  Angle  Rotations  are  not  commutative,  therefore  a  starting  axis  must  be  chosen.  The 
order  applied  here  is  the  standard  order  for  aeronautical  applications,  and  most  readily 


1987),  and  most  readily  adapts  to  aircraft  motions.  This  may  be  because  rolls  usually  have 
the  highest  Euler  Angle  rates,  and  yaws  usually  have  the  lowest  rates.  We  do  not  wish  to 
have  the  rolls  altered  by  follow  on  rotations.  Shoemake  makes  an  argument  for  the  use  of 
quaterr'ons  instead  of  Euler  Angles  for  modeling  transformations.  With  quaternions, 
rotation  order  is  not  a  factor.  Although  it  is  possible  to  convert  between  quaternions  and 
matrices,  Shoemake  describes  such  a  process  as  “ill-defined”.  The  quaternion 
representation  for  rotations  is 

Rot  (/!,0) 

where  tiie  final  orientation  is  a  rotation  of  angle  theta  around  a  single  axis  n.  (Fu  87).  The 
use  of  quaternions  for  the  AU\'  flight  simulation  is  a  moot  point  in  that  the  IRIS  4D 
software  and  hardware  is  based  on  4  x  4  transformation  matrices. 

b.  Vehicle  Coordinate  System  Alignment 

Further  examination  of  Figure  6.12  reveals  that  an  AUV  yaw  occurs  around 
the  vehicles  “z”  axis  or  the  “y”  axis  on  the  world  coordinate  system.  The  difference  in  the 
coordinate  systems  was  described  earlier  in  the  chapter,  but  is  amplified  here.  The  AUV 
object  was  developed  external  to  the  NFS  Simulator,  when  called  into  tlie  program,  the 
vehicle’s  positive  “x”  axis  is  aligned  with  the  world  coordinate  system’s  “-z”  axis.  The 
vehicles  “y”  axis  is  aligned  with  the  world’s  “x”  axis.  Although  not  necessary,  it  would  be 
less  confusing  to  someone  reviewing  the  code  if  the  vehicle  was  ruiesigned  to  be  initially 
aligned  with  the  IRIS  4D  world  coordinate  system. 


2.  Revising  the  Homogeneous  Transform  Matrix 

Thv-  incremental  transformation  is  converted  to  world  coordinates  in  the  routine 
shown  in  Figtire  6.13,  where  the  vehicle’s  homogenous  transformation  matrix  is  updated. 

void  update_H_matrix_from_incremental_changes(auv) 

Sub_pffauv; 

{ 

pushmatrixO; 

loadunitO; 

multmatiix(auv->dyn.H_matrix);  /*  old  rotations  &  translations  */ 
multmatrix(auv->dyn.incremental_H_matrix) 
translate(auv->dyn.pos_change[  1  ], 

-auv->dyn.pos_change{2), 

-auv->dyn.pos_change(0]); 

getmatrix(auv->H_matrix);  /*  new  rotations  &  translations  */ 
popmatrixQ; 

} 


Figure  6.13  Updating  the  Vehicle’s  State 

MuloncurixO  premultiplies  the  top  of  the  stack  by  its  argument,  with  the  new 
value  being  place  on  the  stack(Gr3phic$  Library  1988).  By  prcmultiplying  the  H-matrix  by 
the  inert  cental  H-matrix,  we  have  the  net  effect  of  a  vehicle  mtating  around  its  own  axis. 
If  we  were  to  reverse  the  order,  the  rotations  would  occur  around  the  world  coordinate 
system,  often  used  when  directly  positioning  objects  on  the  screen  using  a  vinual  reality 
input  device  such  as  a  spaceball. 


3.  Extracting  Pitch,  Roll,  and  Heading  information 

Unlike  other  graphic  simulators  at  NPS,  we  have  incorporated  vehicle  translations 
around  all  three  axes,  and  have  done  so  without  ever  tracking  pitch,  roll,  or  heading 
information.  The  vehicle  state  was  maintained  using  the  viewing  matrix,  which  was  coined 
the  “H-matrix”  and  made  part  of  the  AUV  structure.  Why  is  it  then  necessary  to  extract 
pitch,  roll,  and  heading  information?  The  primary  answer  is  to  supply  feedback  via  the  user 
interface  in  a  format  more  readily  assimilated  by  the  user.  A  vehicle  heading  of 045  degrees 
means  more  to  a  user  than  “H-matrix(0]I3]  =  .707"  (which  incidently  means  that  the  vehicle 
is  either  heading  045  degrees  or  3\5  degrees). 

Having  pitch,  heading,  and  roll  information  readily  available  is  helpful  in  other 
ways  also.  When  using  d^/uimic  constraints,  we  may  wish  to  superimpose  a  roll  limitation 
on  our  vehicle.  Pitch  and  heading  information  may  be  helpful  when  utilizing  the  bow 
mounted  sonar,  and  simulating  contact  within  the  sonar  acquisition  cone. 

Pitch  is  limited  to  +/-  90  degrees  whereas  roll  is  limited  to  +/-  180  degrees  and 
heading  ranges  from  0  to  360  degrees.  Pitch  can  be  calculated  directly  from  one  of  two  sine 
values  in  the  matrix.  However,  roll  and  heading,  as  previously  pointed  out,  may  be 
ambiguous.  By  utilizing  the  cosine  information  in  the  H-matrix  diagonals,  this  ambiguity 
can  be  resolved.  The  routine  in  Figure  6.14  shows  the  extracting  process. 
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voidcxtraa_hcading_pitch_and_roll_froni_H_matrix(auY) 

Sub_4)trauv; 

{ 

auv->dyn.hcading  =  -asin(auv->dynil_matrix[2][0])*57.3; 

if  (auv->dyn.H_matrix[2][21  <  0.0){ 
auv->dyn.hcading  =  180- auv->dyn.hcading; 

}  /*  heading  into  “z”  */ 

if  (auv->dyn.heading  <  0){ 
auv->dyn.heading +=  360; 

)  /*  limit  heading  to  360  degrees  */ 

auv->dyn.pitch  = -asin(auv->dyn.H_matrix[2][l])*57.3 

auv->dyn.roll  =  asin(auv->dyn.H_matrix[0][l])*57.3; 

if  (auv->dyn.H_matrix[l][l]>0.0){ 

auv->dyn.roll  =  180  -  auv->dyn'.Toll;  /*  upside  down  */ 

J 

auv->dyn.roU  +=  180;  /*  starting  along  -z  axis  */ 

if  (auv->dyn.r61l>180)  { 
auv->dyn.roll  =  auv->dyn.roll  -  360; 

)  /*  limit  roll  to  360  degrees  V 

if  (auv->dyn.roU<(-180))  { 

auv->dyn.roU  =  360  +  auv->dyn.roll; 

J  /•  limit  roll  to  +/- 180  degrees  */ 

)  /*  end  extract  heading ...  */ 


Figure  6.14  Pitch,  Roll,  &  Yaw 
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F.  DYNAMICS  AND  REAL  TIME  APPLICATIONS 


1.  Dynamics  is  not  the  Limiting  Factor 

With  the  computational  power  of  today’s  high  performance  graphic  workstations, 
dynamics  as  a  means  of  simulating  motion  is  much  more  achievable.  While  streamlining 
the  equations  is  important,  e.g.  lookup  tables  instead  of  trigometric  function  calls, 
multiplication  instead  of  exponential  functions,  the  extra  overhead  was  remarkably  low. 
Two  modes  are  available  with  the  NPS  AUV  HI  Simulator,  non-dynamic  and  dynamic. 

a.  Dynamic  and  Non-dynamic  Modes 

In  the  non-dynamic  mode,  all  the  vehicle  transformations  occur  as  a  result  of 
direct  spaceball  or  mouse  panel  inputs  to  the  Homogeneous  Transform  Matrix.  In  the 
dynamic  mode,  the  inputs  are  sent  to  the  function  dynamicsO.  This  function  computes  the 
cross  flow  viscosity,  solves  equations  of  motion  for  six  axes,  performs  a  matrix 
multiplication  to  produce  an  acceleration  vector,  performs  an  Euler  integration  on  the 
accelerations  and  a  modified  Euler  integration  on  the  velocities,  applies  the  incremental 
position  changes  to  the  incremcntal_H_matrix  which  premultiplics  the  vehicle  H_matrix  to 
obtain  the  revised  vehicle  state. 

b.  Dynamic  Mode  Benchmarks 

Benchmarks  were  obtained  to  compare  the  load  that  the  dynamics  package 
had  on  the  system  frame  rate.  In  the  swimming  pool  with  Cockpit  view,  the  frame  rate  was 
16.2,  with  and  without  the  dynamics  package  activated.  With  the  AUV  display^  along 
with  the  poof,  the  frame  rate  was  7.7,  again,  with  or  without,  the  dynamics  package 
activated.  Whereas  color  presentation,  terrain  resolution,  and  even  panel  interface  display 
had  a  negative  effect  on  frame  rate,  the  use  of  the  dynamics  package  had  none.  My 
conclusion  is  that,  for  this  dynamics  model,  as  long  as  the  mathematics  is  kept  outside  the 
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mesh  drawing  loop,  dynamics  is  an  effective  way  to  model  the  Al^V’s  behavior  in  real 
time. 


2.  Parallel  Processing 

In  anticipation  of  a  heavy  system  drain  due  to  dynamic  equation  calculations,  the 
dynamics  package  was  designed  to  take  advantage  of  the  multiple  processors  of  the  IRIS 
workstation.  Using  barriers,  the  six  general  equations  can  be  solved  simultaneously,  halt 
at  the  barrier  until  all  equations  are  solved,  the  force  &  torque  vector  generated  and 


In  addition  to  solving  the  equations  in  parallel,  on  a  higher  level,  the  dynamics  and 
the  graphics  could  be  done  in  parallel  using  a  producer-consumer  model.  With  the  addition 
of  a  duplicate  H-matrix,  the  graphics  package  could  lag  one  frame  behind  the  dynamics 
package.  Although  the  speed  of  the  dynamics  package  currently  does  not  warrant  the 
overhead  of  parallel  processing,  incorporation  of  dynamic  constraints  and  collision 
detection  could  degrade  performance  to  such  a  level  that  co-processing  can  become  an 
attractive  alternative. 

3.  Addition  of  Dynamic  Constraints 

Dynamic  constraint  checking  can  be  built  on  to  the  tail  end  of  the  dynamics 
package.  If  the  vehicle’s  state  fails  to  abide  by  the  constraints,  the  variables  within  the 
eq>ntions  of  motion  could  be  temporarily  changed,  and  the  vehicle’s  state  sent  back 
through  the  dynamics  package.  When  the  constraints  are  satisfied,  control  returns  to  the 
graphics  package. 
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VII.  NPS  AUV  SIMULATOR 


A.  USER  INTERFACE 

The  User  Interface  was  generated  utilizing  the  NPS  Panel  Designer  (NPSPD) 
(King,  Pievatt  1990).  NPSPD  generates  “C”  code  including  a  primary  graphics  control  loop 
where  the  user  can  pl^  his/her  routines.  Since  the  NPS  AUV  III  Simulator  was  already  a 
working  program,  the  incorporation  of  a  NPSPD  Interface  had  to  be  reversed  engineered. 
The  NPS  AUV  Simulator,  along  with  the  NPS  Material  Editor,  were  the  first  programs  to 
incorporate  NPSPD.  In  the  (King,  Prevatt)  thesis,  there  is  a  chapter  which  describes  how 
the  AUV  simulator  incorporated  NPSPD.  The  main  points  are  covered  here  for 
completeness. 

The  array  of  panels  are  contained  in  the  program  viewer. c,  as  are  some  of  the  panel 
actuators.  As  the  list  of  panels  grew,  it  was  easier  to  track  and  modify  if  each  group  of  panel 
actuators  were  stored  in  separate  files.  The  files  are  tied  into  viewer.c  using  “include” 
preprocessor  statements.  For  instance,  all  the  actuators  on  the  tape  recorder  panel  are  stored 
in  acuator.dir/recorder.act,  although  the  recoixler  panel  itself  is  stored  in  viewer. c. 

When  a  new  panel  of  actuators  is  generated,  the  global  “MAX_PANELS”  in 
viewer. h  must  be  incremented  by  one.  The  array  number  assigned  to  the  panel  and  actuator 
array  mjst  be  one  higher  than  the  most  recent  panel  addition.  The  coefficient  panels  have 
the  most  actuators  with  33.  If  any  new  panel  exceeds  that  amount,  the  MAX_ACTUATOR 
globals  in  viewer. h  must  be  adjusted.  The  path  to  the  panel  library  is  in  the  Makefile. 
Whenever  new  panels  arc  generated,  the  program  must  be  relinked  to  the  library. 
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B.  MASTER  SELECTION  PANEL 


The  Master  Selection  Panel,  shown  in  Figure  7.1,  is  composed  of  two  subsections.  The 
push-button  panel  selections,  and  the  viewing  perspective  panel. 


Figure  7.1  Master  Selection  Panel 


The  viewing  panel  controls  the  “latitude”,  “longitude”,  and  head  “twist”  from  which 
the  vehicle  is  viewed.  There  are  two  distance  bars.  The  one  on  the  left  is  for  small 
adjustments  using  the  left  mouse.  Superfine  adjustments  are  made  using  two  mouse 
buttons,  the  left  and  the  center.  The  right  bar  is  for  making  coarser  adjustment  such  as 
getting  a  “satellite  view”  of  the  California  Coastlirie. 

The  panel  select  panel  primarily  activates  sub-panels,  as  well  as  selects  the 
enviromnent,  bay  or  pool.  “Cockpit  View”  enables  the  user  to  view  the  enviromnent  from 
a  nose  mounted  camera.  AUV  Center,  the  default  selection,  keeps  die  vehicle  in  the  center 
of  the  display;  the  observer  “moves  with  the  vehicle”.  When  deselected,  the  viewer  looks 
at  where  the  vehicle  was  when  the  deselection  was  made.The  vehicle  can  then  actually  be 
flown  out  of  the  field  of  view. 


67 


C.  MOUSE  PANEL 


Although  manual  control  is  primarily  with  the  spaceball,  adjustment  to  control 
siufaces  or  RPM  can  be  made  via  the  mouse  panel.  This  is  useful  not  only  when  there  is  no 
spaceball  with  the  workstation,  but  also  when  it  is  critical  to  activate  one  set  of  con^ . 
only,  a  very  difficult  accomplishment  using  the  six  degree  of  freedom  spaceball.  Tl.e  -.louse 
panel  is  shown  in  Figure  7.2 


Figure  7.2  Mouse  Panel 

Currently  the  Stem  Planes  can  not  be  activated  by  the  mouse  as  tiiey  are  coupled  to 
the  bow  planes.  Rudder  Limits  are  +/-  40  degrees,  and  RPM  limit  is  700. 


D.  PERFORMANCE  PANEL 


Figure  7.3  Performance  Panel 


The  Performance  Panel  displays  a  pai  tial  vehicle  state.  The  Speed  is  calibrated  to  be 
in  knots.  The  gauge  limit  on  the  RPM  is  1000.  The  Depth  meter  indicates  vehicle  depth 
while  the  Floor  meter  shows  bottom  clearance  informations.  Future  expansion  should 
include  a  fin  deflection  meter  for  all  8  control  surfaces,  and  an  RPM  dial  for  each  of  the  six 
thrusters. 
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E.  FRAMES  PANEL 


Figure  7.4  Frame  Panel 


The  Frames  panel  gives  the  workstation’s  poformance  in  two  ways.  Delta  Time  is  the 
total  time  between  swapbutfers,  and  frame  rate  is  the  inverse,  i.e.,  total  frames  per  second. 
Tlie  meters  are  single  pen  stnpchaits  and  are  located  on  the  lower  left  portion  of  the  screen. 
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Figure  7^  Recorder  Panel 

The  recording  is  made  in  the  ASCII  file  “recording”  which  contains  the  initial  \’ehicle 
state  followed  by  times,  ipms  and  fin  deflection  whenever  a  change  of  ipm  on  defelecdon 
occurred.  When  “Record”  is  selected,  it  erases  the  previous  tape.  Playbacks  can  occur  as 
msuiy  times  as  desired  without  erasing  the  tape.  External  scripts  may  be  played  if  they  are 
loaded  to  the  “recording”  file.  The  Tape  Speed  selection  adjusts  the  q>eed  of  playback.  The 
Aux  buttons  are  selectable,  and  available  for  programming  in  the  auvjo  j>aneljnterface.c 
package. 


F.  RECORDER  PANEL 


A: 


The  recorder  panel  provides  the  capability  to  record  and  replay  scenarios. 
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G.  VELOCITIES  PANEL 


The  velocities  panel  shows  accelerations  and  velocities  for  each  of  the  six  degrees  of 
freedom. 


Figure  7.6  Velocities  Panel 


This  panel  is  utilized  to  monitor  die  sta«b  of  the  vehicle  while  running  dynamic  tests. 
Comparisons  with  data  obtained  from  in>pool  testing  should  reveal  whether  or  not  the 
vehicle  is  responding  typropriately.  The  acceleration  values  are  in  feet/sec/sec,  and  the 
velocity  values  are  in  feet/sec.  To  activate  the  panel,  the  Stripcharts  button  must  be 
activated  followed  by  the  Velocities  button.  . 
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H.  BOTTOM  CONTOUR  PANEL 


Figure  7.7  Bottom  Contour 


The  bottom  contour  chart  shows  a  dual  pen  stripchait  that  plots  btxh  the  subm^ne’s 
depth  and  the  depth  of  the  sea  flour.  The  above  chart  shows  the  vehicle  in  essentially  a 
terrain  following  mode.  The  meters  on  die  right  repeat  the  values  that  are  on  the  stripchait. 
By  default,  the  upper  pen  is  red,  and  the  lower  pen  is  black.  The  actuator  is  located  on  the 
upper  right  portion  of  the  screen. 


I.  TERRAIN  PANEL 


Figure  IS  Terrain  Panel 


The  terrain  panel  allows  variable  terrain  resolution  selection,  variable  number  of 
resolution  level  selection,  and  density  of  the  best  resolution  selection.  The  Grid  button 
deselects  filled  mode.  Clipping  activates  the  culling  algorithm  to  eliminate  vertices  outside 
the  field  of  view.  Color  selects  elevation  color  coded  dau  for  display.  The  scale  bar  is  non¬ 
functional  but  available  for  programming. 
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Figure  7.9  Normal  Presentation 


VIII.  FUTURE  DIRECTIONS 


A.  DYNAMIC  CONSTRAINTS  AND  PARALLEL  PROCESSING 

Since  the  incorporation  of  dynamic  constraint  checking  could  require  significant 
overhead,  parallel  processing  of  the  NPS  AUV  Simulator  can  be  advantageous.  Constraint 
checking  could  cause  the  input  parameters  to  the  cquatioi.s  of  motion  to  be  continually 
adjusted,  and  the  equations  resolved  in  a  loop  until  the  constraints  are  satisfied.  Co¬ 
processing  of  the  six  equadons  can  have  a  favorable  effect.  In  addidon,  placing  the  graphics 
routine  and  dynamics/constraints  package  in  parallel  can  be  beneficial  as  well. 

The  vehicle  broaching  the  surface  can  be  emulated  by  adjusdng  the  center  of  buoyancy 
and/or  the  buoyancy  vector.  Normally  the  center  of  buoyancy  is  assumed  to  be  at  the  center 
of  ro'adon,  and  the  buoyancy  is  equal  to  the  weight. 

The  proper  response  of  a  vehicle  collision  with  the  pool  wall  or  floor  is  dependent  on 
what  pan  of  the  vehicle  makes  contact,  and  the  state  of  the  vehicle  at  dme  of  collision.  A 
single  point  force  on  the  vehicle  will  need  to  be  factored  into  the  equadons  until  the 
constraint  is  sadsfled. 

Tne  effect  of  the  vehicle  running  aground  is  similar  to  the  pool  scenario  described 
above,  however,  type  of  bottom,  e.g.,  sand,  rock,  or  silt,  would  need  to  be  considered. 

Since  the  equadons  produce  approximations  of  the  vehicle  behavior,  cenain  input 
parameter  values  can  potentially  display  unrealistic  or  undesired  behavior.  For  example,  it 
may  be  necessary  to  set  a  maximum  positive  and  negative  rpm  on  the  main  thrusters. 

B.  INCORPORATION  OF  PEP’^  ’HERAL  PACKAGES 

1.  Controller 

The  contro  'cr  (autopilot)  package  needs  to  be  incorporated.  The  controller  should 
provide  rpm  and  fin  deflection  information  to  the  AUV  based  upon  desired  heading,  pitch. 
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and  speed.  Using  sliding  mode  control,  the  bow  planes  will  act  independently  of  the  stem 
planes.  Future  controller  improvements  include  separate  control  mode  for  all  eight 
surfaces,  and  a  hovering  mode  using  the  venical  and  horizontal  thruster. 

2.  Navigator 

The  navigator  will  compute  desired  heading,  pitch,  and  speed  based  upon 
waypoint  data  (3D  position  and  time  on  top).  If  drift  is  detected  based  upon  doppler  sonar 
information,  this  should  be  included  in  the  computation.  If  predicted  current  information  is 
available,  that  should  be  included  in  the  “dead  reckoning  (DR)”  process.  The  DR  position 
can  be  “fixed”  using  bottom  contour  information  available  in  the  environmental  data  base. 

3.  Mission  Planner/Replanner 

The  mission  planner  would  generate  desired  waypoints  based  upon  the  specific 
mission  of  the  submarine,  e.g.  bottom  mapping,  main  countermeasures,  special  forces 
support,  etc..  The  replanner  would  regenerate  waypoints  based  upon  newly  available 
infonnation,  e.g.  unplanned  obsucles,  vehicle  emergency,  enemy  detection,  revised 
mission,  etc.. 

C.  TERRAIN 

The  VTRA  needs  to  be  expanded  to  include  multiple  data  cells.  Since  VTRA  supports 
a  grid  database,  such  as  that  available  from  DMA,  submarine  missions  can  be  simulated 
nearly  anywhere  worldwide.  Based  on  vehicle’s  speed,  direction,  and  horizon,  adjacent 
grid  cells  will  need  to  be  transferred  from  peripheral  storage  to  primary  storage 
automatically.  VTRA  will  need  to  be  enhanced  to  manage  the  data  transfer,  and  terrain  cell 
management 

Elevation  coded  terrain  coloring  should  be  incorporated.  The  elevation  data  needs  to 
be  checked  and,  if  required,  a  new  lighting  model  generated,  for  each  vertex  in  the  graphics 
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pipeline.  Texturing  is  a  another  alternative  to  displaying  realistic  terrain  as  demonstrated 
on  NPSNET,  and  should  be  incorporated. . 

D.  AUV  MODEL  DRAWING 

The  AUV  is  currently  drawn  using  polygons  and  surfaces.  By  drawing  the  hull  and  fins 
as  meshes,  vehicle  appearance  can  be  maintained  while  reducing  the  graphics  pipeline  load 
as  described  earlier.  With  mesh  drawing,  an  algorithm  similar  to  VTRA  could  be  developed 
to  display  the  AUV  at  various  resolution  levels.The  NFS  Object  File  Format  (OFF)  is 
currently  being  revised  to  incorporate  articulated  objects.  Future  redrawing  of  the  vehicle 
should  be  based  upon  the  future  OFF  design.  Colors  should  be  carefully  chosen  so  as  to  be 
compatible  with  NTSC  displays.  RGB  warm  colors  (red,  orange,  etc.)  often  get  distorted 
when  convened  to  NTSC,  an  should  be  viewed  prior  to  selection  using  the  NFS  Material 
Editor  (NFSME)  (Anderson  1990). 

E.  CONCLUSIONS 

The  Variable  Terrain  Resolution  Algorithm  enables  terrain  grid  databases,  such  as 
DMA  DT^,  to  be  displayed  with  further  horizons  and  minimal  loss  of  graphic  display 
speed,  while  maintaining  high  resolution  terrain  near  the  observer.  The  dynamics  of  the 
AUV  can  be  modeled  in  real  tiiiie.  Hydrodynamic  coefficients  can  be  adjusted  on  line  for 
a  quick  refinement  of  the  vehicle’s, performance  characteristics.  The  NFS  AUV  Simulator 
can  enhance  vehicle  software  development  without  actual  in  water  trials.  Dynamics  can  be 
adapted  to  other  NFS  Siniulators  by  incorporating  the  rigid  body  dynamic  model  used  in 
the  AUV  Simulator. 
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